unknown
1970-01-01 00:00:00 UTC
--20cf300514b220300c04a58a63e7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
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 <i>static </i>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.<div> <div><br><div><div class="gmail_quote">On Sun, Jun 12, 2011 at 1:22 PM, Mark S. Miller <span dir="ltr"><<a href="mailto:***@google.com">***@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div>[+kenneth.kahn, +danfuzz, +douglas (barnes), +ehud.shapiro, +carl, +chip]</div><div><br></div>On Sun, Jun 12, 2011 at 3:54 AM, Constantine Plotnikov <span dir="ltr"><<a href="mailto:***@gmail.com" target="_blank">***@gmail.com</a>></span> wrote:<br> <div class="gmail_quote"><div>[...]�</div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>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.</div> </div></blockquote><div><br></div></div>On Sun, Jun 12, 2011 at 10:48 AM, Dean Tribble <span dir="ltr"><<a href="mailto:***@e-dean.com" target="_blank">***@e-dean.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex">
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. [...]</blockquote><div><br></div><div>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 <<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 contribute to this thread, please first subscribe at <<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 silently rejected.</div> <div><br></div><div><br></div><div>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.</div> <div><br></div><div>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.</div> <div><br></div><div>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 <<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>>). 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?</div>
<div><br></div><div>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. </div>
<div><br></div><div>
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
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 <i>static </i>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.<div> <div><br><div><div class="gmail_quote">On Sun, Jun 12, 2011 at 1:22 PM, Mark S. Miller <span dir="ltr"><<a href="mailto:***@google.com">***@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div>[+kenneth.kahn, +danfuzz, +douglas (barnes), +ehud.shapiro, +carl, +chip]</div><div><br></div>On Sun, Jun 12, 2011 at 3:54 AM, Constantine Plotnikov <span dir="ltr"><<a href="mailto:***@gmail.com" target="_blank">***@gmail.com</a>></span> wrote:<br> <div class="gmail_quote"><div>[...]�</div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>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.</div> </div></blockquote><div><br></div></div>On Sun, Jun 12, 2011 at 10:48 AM, Dean Tribble <span dir="ltr"><<a href="mailto:***@e-dean.com" target="_blank">***@e-dean.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex">
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. [...]</blockquote><div><br></div><div>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 <<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 contribute to this thread, please first subscribe at <<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 silently rejected.</div> <div><br></div><div><br></div><div>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.</div> <div><br></div><div>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.</div> <div><br></div><div>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 <<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>>). 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?</div>
<div><br></div><div>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. </div>
<div><br></div><div>