"Mark S. Miller" <= erights@google.com</a>><br>
1970-01-01 00:00:00 UTC
--0015174c443ad35a9a04a590af6b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Hi all.<div><br></div><div>"Objects a Fresh Look" can be found here:</div><div><br></div><div><a href="http://users.ox.ac.uk/~oucs0030/Papers/objects_a_fresh_look.pdf">http://users.ox.ac.uk/~oucs0030/Papers/objects_a_fresh_look.pdf</a></div> <div><br></div><div>Regarding the origins of some the underlying intuitions perhaps we need to go back to Carl Hewitt in the early and mid 1970s. Carl once motivated Actors with the idea that programming in small should be more like programming in the large (i.e., distributed computing). How do you program interactions with a remote service? You send asynchronous messages. With hindsight it might have been better to view the remote service as more like a vat. Then actors would have naturally had multiple mailboxes.</div> <div><br></div><div>Best,</div><div><br></div><div>-ken<br><br><div class="gmail_quote">On 12 June 2011 22:10, <span dir="ltr"><<a href="mailto:***@salguod.com">***@salguod.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Mark--<br>
<br>
For what it's worth, while there may have been a dispute going on, I don't recall being directly involved in it or feeling any "business panic". My motivation was simple impatience and a desire to start coding something. This may have dovetailed with something like a "business panic" on the part of others, but I can't speak to that.<br>
<br>
Cheers,<br>
Doug<br>
<br>
-----Original Message-----<br>
From: "Mark S. Miller" <<a href="mailto:***@google.com">***@google.com</a>><br>
Sent: Sunday, June 12, 2011 4:22pm<br>
To: "Discussion of E and other capability languages" <<a href="mailto:e-***@mail.eros-os.org">e-***@mail.eros-os.org</a>>, "Ken Kahn" <<a href="mailto:***@oucs.ox.ac.uk">***@oucs.ox.ac.uk</a>>, "Dan Bornstein" <<a href="mailto:***@google.com">***@google.com</a>>, "Douglas Barnes" <<a href="mailto:***@salguod.com">***@salguod.com</a>>, "Ehud Shapiro" <<a href="mailto:***@weizmann.ac.il">***@weizmann.ac.il</a>>, "Carl Hewitt" <<a href="mailto:***@concurrency.biz">***@concurrency.biz</a>>, "Chip Morningstar" <<a href="mailto:***@fudco.com">***@fudco.com</a>><br>
Subject: Re: [e-lang] Question about E's history.<br>
<br>
[+kenneth.kahn, +danfuzz, +douglas (barnes), +ehud.shapiro, +carl, +chip]<br>
<br>
On Sun, Jun 12, 2011 at 3:54 AM, Constantine Plotnikov <<br> <a href="mailto:***@gmail.com">***@gmail.com</a>> wrote:<br>
[...]<br>
<br>
> It would be interesting to know how this idea of Vat comes to E. I'm also<br>
> interested whether there are other Actor model implementations (that declare<br>
> that they such) where asynchronous components could share single event loop.<br>
><br>
<br>
On Sun, Jun 12, 2011 at 10:48 AM, Dean Tribble <<a href="mailto:***@e-dean.com">***@e-dean.com</a>> wrote:<br>
<br>
> Agreed. The larger islands of sequential programming in E were quite a<br>
> benefit for many kinds of programming, and is probably the key insight in<br>
> [the] E computational model. [...]<br>
<br>
<br>
Thanks. To explain how E arrived at this insight, a bit of history. The<br>
following is all based on my old flawed memories, so cc'ing various involved<br>
people for corrections and gap-filling. For those new to this thread, more<br>
context can be found starting at <<br> <a href="http://www.eros-os.org/pipermail/e-lang/2011-June/013865.html" target="_blank">http://www.eros-os.org/pipermail/e-lang/2011-June/013865.html</a>>. To<br>
contribute to this thread, please first subscribe at <<br> <a href="http://www.eros-os.org/mailman/listinfo/e-lang" target="_blank">http://www.eros-os.org/mailman/listinfo/e-lang</a>> or your messages will be<br>
silently rejected.<br>
<br>
<br>
Ehud Shapiro's 1983 paper "A subset of Concurrent Prolog and its<br>
Interpreter" began the field of concurrent logic programming. That same<br>
year, Shapiro (cc'ed) and Takeuchi's "Object-oriented programming in<br>
concurrent Prolog" showed how to encode actors as a pattern of concurrent<br>
logic programming, by reifying the "mailbox" as a stream of incoming<br>
messages, provided by convention as a first argument to a goal. In 1987, Ken<br>
Kahn, Dean Tribble, Danny Bobrow, and myself formed the Vulcan project at<br>
PARC, initially to provide sugar to more directly express actors/objects on<br>
top of this concurrent logic programming base.<br>
<br>
Dean diagnosed and fixed a flaw in an early draft of "Vulcan: Logical<br>
Concurrent Objects", and in so doing invented the inner-vs-outer send<br>
technique which would later show up in Joule and become so important to our<br>
E story below. An outer send would append onto the tail of a stream of<br>
messages, adding a new message to be serviced after all previously queued<br>
messages. An inner send, it you had the capabilities needed to express it,<br>
would prepend a message onto the head of the stream of messages, to be<br>
servived ahead of all previously queued messages.<br>
<br>
Vijay Saraswat (hi Vijay -- it's good to see you here!) joined the Vulcan<br>
project soon afterwards. We never really made much use of our sugar, finding<br>
it didn't add much convenience and hid too much of the underlying power. And<br>
a good thing too. The sugar would have baked in the one-mailbox-per-actor<br>
assumption. By programming more directly on the base, we came to realize the<br>
power of having a single actor (or concurrent logic programming perpetual<br>
process) serve multiple mailboxes. This power is explained well in Ken<br>
Kahn's "Objects: A Fresh Look" (the crucial text seems to be in the pages<br>
missing between p217 and p220 in <<br> <a href="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" target="_blank">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</a>>).<br>
Of the Vulcaneers, Ken (cc'ed) may have also originated this technique; I<br>
don't remember. Ken, do you have the full paper online? Do you remember how<br>
we came to realize the significance of this pattern?<br>
<br>
Joule had two levels of semantic description. At the lower kernel layer,<br>
Joule was a pure actors language with a single implicit mailbox per actor.<br>
At the higher layer, which was more convenient for both users and<br>
implementors, a Joule actor had multiple facets -- directly supporting the<br>
power we'd discovered in the Vulcan project, that Ken's paper explains so<br>
well. A Joule actor as a whole still processed only one event at a time, but<br>
could service multiple mailboxes, one for each of its facets. In this way, a<br>
Joule actor was a cheap unit of atomicity among multiple services being<br>
provided from common state. I would count this as the first foundational<br>
step away from the "active objects" view of actors that Tom mentioned. Joule<br>
coupled this with (at this higher layer) direct support for inner-vs-outer<br>
sends.<br>
<br>
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Hi all.<div><br></div><div>"Objects a Fresh Look" can be found here:</div><div><br></div><div><a href="http://users.ox.ac.uk/~oucs0030/Papers/objects_a_fresh_look.pdf">http://users.ox.ac.uk/~oucs0030/Papers/objects_a_fresh_look.pdf</a></div> <div><br></div><div>Regarding the origins of some the underlying intuitions perhaps we need to go back to Carl Hewitt in the early and mid 1970s. Carl once motivated Actors with the idea that programming in small should be more like programming in the large (i.e., distributed computing). How do you program interactions with a remote service? You send asynchronous messages. With hindsight it might have been better to view the remote service as more like a vat. Then actors would have naturally had multiple mailboxes.</div> <div><br></div><div>Best,</div><div><br></div><div>-ken<br><br><div class="gmail_quote">On 12 June 2011 22:10, <span dir="ltr"><<a href="mailto:***@salguod.com">***@salguod.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Mark--<br>
<br>
For what it's worth, while there may have been a dispute going on, I don't recall being directly involved in it or feeling any "business panic". My motivation was simple impatience and a desire to start coding something. This may have dovetailed with something like a "business panic" on the part of others, but I can't speak to that.<br>
<br>
Cheers,<br>
Doug<br>
<br>
-----Original Message-----<br>
From: "Mark S. Miller" <<a href="mailto:***@google.com">***@google.com</a>><br>
Sent: Sunday, June 12, 2011 4:22pm<br>
To: "Discussion of E and other capability languages" <<a href="mailto:e-***@mail.eros-os.org">e-***@mail.eros-os.org</a>>, "Ken Kahn" <<a href="mailto:***@oucs.ox.ac.uk">***@oucs.ox.ac.uk</a>>, "Dan Bornstein" <<a href="mailto:***@google.com">***@google.com</a>>, "Douglas Barnes" <<a href="mailto:***@salguod.com">***@salguod.com</a>>, "Ehud Shapiro" <<a href="mailto:***@weizmann.ac.il">***@weizmann.ac.il</a>>, "Carl Hewitt" <<a href="mailto:***@concurrency.biz">***@concurrency.biz</a>>, "Chip Morningstar" <<a href="mailto:***@fudco.com">***@fudco.com</a>><br>
Subject: Re: [e-lang] Question about E's history.<br>
<br>
[+kenneth.kahn, +danfuzz, +douglas (barnes), +ehud.shapiro, +carl, +chip]<br>
<br>
On Sun, Jun 12, 2011 at 3:54 AM, Constantine Plotnikov <<br> <a href="mailto:***@gmail.com">***@gmail.com</a>> wrote:<br>
[...]<br>
<br>
> It would be interesting to know how this idea of Vat comes to E. I'm also<br>
> interested whether there are other Actor model implementations (that declare<br>
> that they such) where asynchronous components could share single event loop.<br>
><br>
<br>
On Sun, Jun 12, 2011 at 10:48 AM, Dean Tribble <<a href="mailto:***@e-dean.com">***@e-dean.com</a>> wrote:<br>
<br>
> Agreed. The larger islands of sequential programming in E were quite a<br>
> benefit for many kinds of programming, and is probably the key insight in<br>
> [the] E computational model. [...]<br>
<br>
<br>
Thanks. To explain how E arrived at this insight, a bit of history. The<br>
following is all based on my old flawed memories, so cc'ing various involved<br>
people for corrections and gap-filling. For those new to this thread, more<br>
context can be found starting at <<br> <a href="http://www.eros-os.org/pipermail/e-lang/2011-June/013865.html" target="_blank">http://www.eros-os.org/pipermail/e-lang/2011-June/013865.html</a>>. To<br>
contribute to this thread, please first subscribe at <<br> <a href="http://www.eros-os.org/mailman/listinfo/e-lang" target="_blank">http://www.eros-os.org/mailman/listinfo/e-lang</a>> or your messages will be<br>
silently rejected.<br>
<br>
<br>
Ehud Shapiro's 1983 paper "A subset of Concurrent Prolog and its<br>
Interpreter" began the field of concurrent logic programming. That same<br>
year, Shapiro (cc'ed) and Takeuchi's "Object-oriented programming in<br>
concurrent Prolog" showed how to encode actors as a pattern of concurrent<br>
logic programming, by reifying the "mailbox" as a stream of incoming<br>
messages, provided by convention as a first argument to a goal. In 1987, Ken<br>
Kahn, Dean Tribble, Danny Bobrow, and myself formed the Vulcan project at<br>
PARC, initially to provide sugar to more directly express actors/objects on<br>
top of this concurrent logic programming base.<br>
<br>
Dean diagnosed and fixed a flaw in an early draft of "Vulcan: Logical<br>
Concurrent Objects", and in so doing invented the inner-vs-outer send<br>
technique which would later show up in Joule and become so important to our<br>
E story below. An outer send would append onto the tail of a stream of<br>
messages, adding a new message to be serviced after all previously queued<br>
messages. An inner send, it you had the capabilities needed to express it,<br>
would prepend a message onto the head of the stream of messages, to be<br>
servived ahead of all previously queued messages.<br>
<br>
Vijay Saraswat (hi Vijay -- it's good to see you here!) joined the Vulcan<br>
project soon afterwards. We never really made much use of our sugar, finding<br>
it didn't add much convenience and hid too much of the underlying power. And<br>
a good thing too. The sugar would have baked in the one-mailbox-per-actor<br>
assumption. By programming more directly on the base, we came to realize the<br>
power of having a single actor (or concurrent logic programming perpetual<br>
process) serve multiple mailboxes. This power is explained well in Ken<br>
Kahn's "Objects: A Fresh Look" (the crucial text seems to be in the pages<br>
missing between p217 and p220 in <<br> <a href="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" target="_blank">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</a>>).<br>
Of the Vulcaneers, Ken (cc'ed) may have also originated this technique; I<br>
don't remember. Ken, do you have the full paper online? Do you remember how<br>
we came to realize the significance of this pattern?<br>
<br>
Joule had two levels of semantic description. At the lower kernel layer,<br>
Joule was a pure actors language with a single implicit mailbox per actor.<br>
At the higher layer, which was more convenient for both users and<br>
implementors, a Joule actor had multiple facets -- directly supporting the<br>
power we'd discovered in the Vulcan project, that Ken's paper explains so<br>
well. A Joule actor as a whole still processed only one event at a time, but<br>
could service multiple mailboxes, one for each of its facets. In this way, a<br>
Joule actor was a cheap unit of atomicity among multiple services being<br>
provided from common state. I would count this as the first foundational<br>
step away from the "active objects" view of actors that Tom mentioned. Joule<br>
coupled this with (at this higher layer) direct support for inner-vs-outer<br>
sends.<br>
<br>