Loose type checking in E

[Tyler Close]

>Date: Wed, 14 Oct 1998 05:26:07 -0400
>To: "Mark S. Miller" <markm@erights.org>
>From: Tyler Close <tyler@lfw.org>
>Subject: Re: Loose type checking in E
>In-Reply-To: <3.0.3.32.19981013215806.01579434@mail.erights.org>
>References: <3.0.6.32.19981012202428.009221f0@www.lfw.org>
<199810121802.LAA14295@groucho.communities.com>
>
>Well, we have now jumped headlong into the realm of the theoretical. This
is fine with me, I like the theoretical and, when it comes to software
design, I spend an inordinate amount of time thinking about it. That said,
there is a practical purpose to this mailing list, so anytime you want to
put this thread to bed, just give me the high sign. I'll enjoy it while it
lasts.
>
>At 09:58 PM 10/13/98 -0700, you wrote:
>>At 08:24 PM 10/12/98 -0400, Tyler Close wrote:
>>>My concern is that you may have stretched this paradigm [only asynchrony
>>>between vats] beyond its natural bounds. 
>>
>>>From where does one get prior knowledge of the bounds of a paradigm?  
>
>One doesn't. As you can see, I tried to couch my thought in as many
hypotheticals as seemed reasonable.
>
>>Only
>>by stretching a paradigm until it breaks (or at least shows stress) to we
>>find out what its bounds are.  Microcosm was E's first big stretch, and it
>>held up better than could have been expected.
>
>I do not agree that trial and error is the ultimate guide.
>
>All processes have a certain modus operandi. Design is about discovering
this modus operandi and exposing it. Based on our experiences, we can try
to conjecture about the modus operandi of other processes and processes in
general.
>
>>>Asynchronous communication does not make sense for communication
>>>between vats located on the same physical computer. This is bad since this
>>>type of communication will be more prevalent.
>>
>>Argument by assertion?
>
>Your right, I'm sorry.
>
>Different threads on the same computer can, and often need to, share a
common data structure. To prove this point, I reason that the number of
possible execution paths through a data structure far exceed the number of
currently active paths. Furthermore, each of these execution paths has a
sequential progression to it. Forcing a sequential execution path to
communicate asynchronously with the next required object adds concurrency
to a process that is only sequential. Complexity has been added that is not
inherent in the problem. After all, the data is right there, ready to be had.
>
>>>>And don't discount just how difficult a problem ...
>>>>... One of our mantras became "Threads Are Evil".
>>>
>>>This is like saying "Recursion is Evil" because some dopey C programmer
>>>will try to break out of the recursion by doing a goto to some other line
>>>in the program.
>>
>>Or like saying that self-modifying code is evil, or that goto's are evil,
>>or that pointer arithmetic is evil.  Note that in a von Neumann machine,
>>code is actually held in mutable memory, flow control actually happens with
>>goto's, and object-state actually lives in arithmetically addressable
>>memory.  Useful and beautiful things have been done with all three that
>>aren't possible under the corresponding three restrictions.  Are we
>>stretching something-or-other beyond natural bounds to impose these
>>restrictions?
>
>My point was that any tool, even an obviously useful one, can be perverted
by incorrect usage.
>
>I have a degree in Computer Engineering. I understand the general design
principles of my PC.
>
>As you say, at its most basic level, the PC operates using goto's and
pointer arithmetic. Object-oriented programming, the paradigm that has
declared your three enumerated tools to be "Evil", is a protocol for making
disciplined use of the banished tools. It then banished the tools so that
all use of the tools would follow it's newly defined discipline.
>
>I expressed a *concern* that your banishing of threads *may* be a stretch
because you are not disciplining the use of threads, but trying to
homogenize the network environment with the PC environment.
>
>>
>>Our ability to get computers to do things is limited mostly by how much we
>>can say before we've gotten hopelessly confused by what we've said.
>
>Well put.
>
>>Sometimes we get more power by inventing new powerful primitives, but
>>sometime we get more power from figuring out which powerful primitives to
>>avoid.  The key for the above three is that the primitives given up, though
>>seductive on small examples, create a complexity/confusion burden that
>>increase badly when applied over and over and over again in composition.  E
>>postulates this is true for conventional threading/locking as well.  But
>>we'll only know by seeing what we can create without them, and how well.
>
>Well, I guess this is a question of perspective. As I explained above,
another way of looking at it is that we finally found the correct way to
compose the primitives.
>
>>>When doing multithreaded programming, you have to establish a certain code
>>>of ethics that will not be broken. I agree that there are many unethical
>>>programmers out there; however, I have found that it is possible to embed
>>>this code of ethics within the way that the library is naturally used.
>>
>>The fewer such codes a programmer need be simultaneously burdened with, and
>>the less non-local information they must keep track of to preserve
>>consistency, the better.
>
>I thought I said that the code of ethics was embedded within the way that
the library is naturally used. This means that I'm not creating a burden.
In fact, I would argue that I'm giving the programmer more power by giving
them disciplined use of a powerful primitive, as per your path to success
layed out above.
>
>>
>>What is this "consistency under concurrency" problem anyway?  Where is the
>>difficulty?  I used to buy the standard CS line that we should think in
>>terms of preserving object invariants (predicates over the local
>>heap-state).  Though it's probably formally equivalent at some weird level,
>>I find it easier to think about avoiding computing from no-longer-valid
>>assumptions.  For a bare start on some Hayekian ramblings on all this, see
>>http://erights.org/doc/elib/elibmanual.pdf Chapter "Concurrency Control",
>>Section "Safety: Preserving Consistency".
>
>Wow, you sort of lost me in this paragraph. I'll add the link to my
homework though.
>
>Processing, synchronously, now,
>Tyler
>
>:)  :)
>