Re: Question about E's history.

That all sounds right to me, and is much more thorough than my summary :).
 I'll add one more tidbit about relation between Joule and E:  the Joule
implementation used "thick pointers" where each object pointer had two
parts, a pointer a behavior and a pointer to state (where that was either a
simple value field or a heap-allocated record). That allowed multiple facets
to simply be different behavior pointers with the same state pointer.  The
high level semantics of Joule had essentially a *static *set of facets per
Joule server (i.e., different behavior pointers), where the server was the
state boundary, as described below. However the runtime didn't have that
limitation. That difference was niggling, and we were finding places where
we might leverage the additional power that was syntactically not available.
As the E execution model crystallized, the fact that it could potentially
access that expressiveness seemed a confirmation that it was a good design
point.

On Sun, Jun 12, 2011 at 1:22 PM, Mark S. Miller <[email protected]> wrote:

> [+kenneth.kahn, +danfuzz, +douglas (barnes), +ehud.shapiro, +carl, +chip]
>
> On Sun, Jun 12, 2011 at 3:54 AM, Constantine Plotnikov <
> [email protected]> wrote:
> [...]
>
>> It would be interesting to know how this idea of Vat comes to E. I'm also
>> interested whether there are other Actor model implementations (that declare
>> that they such) where asynchronous components could share single event loop.
>>
>
> On Sun, Jun 12, 2011 at 10:48 AM, Dean Tribble <[email protected]> wrote:
>
>> Agreed. The larger islands of sequential programming in E were quite a
>> benefit for many kinds of programming, and is probably the key insight in
>> [the] E computational model. [...]
>
>
> Thanks. To explain how E arrived at this insight, a bit of history. The
> following is all based on my old flawed memories, so cc'ing various involved
> people for corrections and gap-filling. For those new to this thread, more
> context can be found starting at <
> http://www.eros-os.org/pipermail/e-lang/2011-June/013865.html>. To
> contribute to this thread, please first subscribe at <
> http://www.eros-os.org/mailman/listinfo/e-lang> or your messages will be
> silently rejected.
>
>
> Ehud Shapiro's 1983 paper "A subset of Concurrent Prolog and its
> Interpreter" began the field of concurrent logic programming. That same
> year, Shapiro (cc'ed) and Takeuchi's "Object-oriented programming in
> concurrent Prolog" showed how to encode actors as a pattern of concurrent
> logic programming, by reifying the "mailbox" as a stream of incoming
> messages, provided by convention as a first argument to a goal. In 1987, Ken
> Kahn, Dean Tribble, Danny Bobrow, and myself formed the Vulcan project at
> PARC, initially to provide sugar to more directly express actors/objects on
> top of this concurrent logic programming base.
>
> Dean diagnosed and fixed a flaw in an early draft of "Vulcan: Logical
> Concurrent Objects", and in so doing invented the inner-vs-outer send
> technique which would later show up in Joule and become so important to our
> E story below. An outer send would append onto the tail of a stream of
> messages, adding a new message to be serviced after all previously queued
> messages. An inner send, it you had the capabilities needed to express it,
> would prepend a message onto the head of the stream of messages, to be
> servived ahead of all previously queued messages.
>
> Vijay Saraswat (hi Vijay -- it's good to see you here!) joined the Vulcan
> project soon afterwards. We never really made much use of our sugar, finding
> it didn't add much convenience and hid too much of the underlying power. And
> a good thing too. The sugar would have baked in the one-mailbox-per-actor
> assumption. By programming more directly on the base, we came to realize the
> power of having a single actor (or concurrent logic programming perpetual
> process) serve multiple mailboxes. This power is explained well in Ken
> Kahn's "Objects: A Fresh Look" (the crucial text seems to be in the pages
> missing between p217 and p220 in <
> http://books.google.com/books?id=oiAkSgoiz6EC&lpg=PA207&ots=ShwbQwMNp9&dq=%22objects%20a%20fresh%20look%22%20kahn&pg=PA207#v=onepage&q=%22objects%20a%20fresh%20look%22%20kahn&f=false>).
> Of the Vulcaneers, Ken (cc'ed) may have also originated this technique; I
> don't remember. Ken, do you have the full paper online? Do you remember how
> we came to realize the significance of this pattern?
>
> Joule had two levels of semantic description. At the lower kernel layer,
> Joule was a pure actors language with a single implicit mailbox per actor.
> At the higher layer, which was more convenient for both users and
> implementors, a Joule actor had multiple facets -- directly supporting the
> power we'd discovered in the Vulcan project, that Ken's paper explains so
> well. A Joule actor as a whole still processed only one event at a time, but
> could service multiple mailboxes, one for each of its facets. In this way, a
> Joule actor was a cheap unit of atomicity among multiple services being
> provided from common state. I would count this as the first foundational
> step away from the "active objects" view of actors that Tom mentioned. Joule
> coupled this with (at this higher layer) direct support for inner-vs-outer
> sends.
>
> From outside an object, one could only do outer-sends to the object,
> corresponding directly to actor-style asynchronous messages. Only from
> inside an object could you express self-inner-sends to any of your own
> facets, and so get something resembling the stacking behavior of sequential
> languages. Only when this "stack" unwound would the object become receptive
> to the next incoming outer message.
>
> As context for those new to this thread, earlier I wrote
>
> [...] Doug Barnes first created Original-E, by shoehorning Joule-inspired
> concurrency onto a Java base in an intense two week efforts driven by a
> business panic, after a contractual dispute between Agorics (creator,
> provider, and supporter of Joule, where I was) and Electric Communities
> (using Joule to create a decentralized secure virtual reality, where Doug
> Barnes was). I only joined E.C. a year or so later, in 1995, whereupon I
> took over leadership of the Original-E effort.
>
>
> The significance of that step cannot be underestimated. Prior to this, all
> the Actors and concurrent logic work that I was aware of assumed that, to
> get a language with a sensible concurrency control model (e.g., actors or
> concurrent logic programming), you had to start with concurrency. After all,
> the previous attempts we were aware of adding concurrency to a sequential
> language base, including Multilisp btw, but including the earlier efforts of
> geniuses like Dijkstra (semaphores) and Hoare (monitors), all ended up
> making the shared state concurrency mistake, i.e., shared memory
> multithreading with fine grained locking. For the Vulcaneers, this view had
> been reinforced at PARC, as the other concurrency crowd there was developing
> Cedar, an outgrowth of Mesa, which proceeded to inspire the Modula-Ns, where
> very smart people made this mistake everywhere. (Hoare's CSP and
> ccam avoided this mistake, but at such a severe loss of expressiveness that
> we did not take it seriously.)
>
> Looking at the results of Doug Barnes' two week effort, it was clear that
> there was never any necessary conflict all along, but none of us had been
> able to see it. The Joule concurrency constructs, grafted onto a sequential
> Java base, did not push that base towards shared state concurrency. However,
> even by the time I arrived at E.C., the Joule-like concurrency that Doug
> added was not quarantined from Java's shared state concurrency, leaving a
> mess. (I would argue that Scala today makes the same mistake.)
>
> At E.C., Danfuzz Bornstein and I brought vats to Original-E, finally fully
> separating Original-E's Joule-like concurrency from the hazards of Java's
> shared state concurrency. In some ways the Original-E vat was based on the
> Joule "tank", serving as a unit of preemptive termination and transparent
> distribution. But this didn't help regarding concurrency models, as a Joule
> tank, like an Actors worker, was still pervasively concurrent internally.
> Instead, I realized that an Original-E vat was, in this sense, like a single
> big highly-multi-faceted single Joule actor, where each locally exported
> object acts as a distinct facet of the vat. In this context, Joule's inner
> send became conventional LIFO immediate call-return, which any object within
> a vat could only immediate-call other objects within the same vat. Whereas
> anyone could do an eventual send to a facet of a vat, i.e., any object
> within a vat they had a reference to, which would only queue up on the end
> of the queue. The two-ended dequeue nature of Original-E's stack + pending
> deliver queue is in this sense a direct reflection of the inner-send fix
> that Dean contributed to that first Vulcan paper.
>
> On Sun, Jun 12, 2011 at 10:48 AM, Dean Tribble <[email protected]> wrote:
>
>> [...] A straightforward interpretation of "coarse-grained actor" would
>> have multiple capabilities into the shared state of the "actor". The
>> important addition is that, in a vat, the set of capabilities available from
>> outside the vat to the state in the vat can change dynamically. Thus, I
>> think of is as a worthy alternative to fine-grained actors models.
>
>
> Exactly. The hard part for me of getting from Joule to this repair of
> Original-E was to see a local heap of sequential objects as a large
> multi-faceted actor, and to realize that exporting a previously unexported
> object from within this local heap was like *dynamically* adding a facet to
> a Joule actor, which was not possible in Joule. Once I took on this shift of
> perspective, much of the rest followed naturally.
>
> The mechanics of Original-E references was still problematic, as Joule's
> multichannels did not co-exist with sequentiality all that smoothly,
> especially regarding problem reporting. In 1998, when Chip Morningstar
> (cc'ed) and I derived E from Original-E, I returned to many aspects of
> Xanadu's promise system that Joule had left behind. Sometime in early 1998,
> when I sketched the eight hand drawn pages scanned in at <
> http://erights.org/e/semantics.html> all this came together into the
> reference mechanics of modern E.
>
> --
>     Cheers,
>     --MarkM
>
> _______________________________________________
> e-lang mailing list
> [email protected]
> http://www.eros-os.org/mailman/listinfo/e-lang
>
>

_______________________________________________
e-lang mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/e-lang