[e-lang] E is data-flow, not control-flow, correct?
markm at caplet.com
Sat Jul 24 17:49:56 EDT 2004
At 11:36 PM 7/22/2004 Thursday, zuzu wrote:
>please forgive my ignorance, i'm new to E, though i'm reading through
No apologies necessary -- I love to hear from people new to E. Welcome!
>although i am very enthusiastic about secure distributed objects, i
>have conerns about -- E seemingly built upon Java (not unlike SALSA)
>-- that it is not a "pure actor" language nor is it "data flow"
>(rather than "control flow").
In many ways, E's starting point was Actors.
(See http://www.erights.org/history/overview.html )
E's most important and most E-like ancestor is Joule
http://www.agorics.com/Library/joule.html , which is a pure Actors language
As Shap (Jonathan Shapiro) says, the E language definition is in no way tied
to Java specifically. But E is a compromise between pure actors and
conventional sequential call-return object programming. This compromise
comes from the desire to seem instantly familiar to those coming from the C
syntactic tradition. In explaining E to others, Java is our main point of
reference. In deciding on conventions, Java was again our main starting point.
Our compromise is not a hodge-podge mixture of the two paradigms. Rather, it
is a principled nesting of one in the other. At Vat granularity, E remains a
pure actors language. A Vat is an actor-configuration -- essentially an
actor, but with multiple incoming mailboxes (one for each target of an
incoming remote reference). A Vat turn
http://www.erights.org/elib/concurrency/turns.html then corresponds
precisely to an actor event: During each Vat turn, a Vat sends outgoing
asynchronous (eventual) messages and computes the new vat-state it
"becomes" -- the one in which it will process the next message. From this
perspective, E's immediate calls and assignments are internal to an
individual actor event.
Within an actor event, then, we are programming in the conventional familiar
call-return sequential object model. E's individual objects are, from this
perspective, not actors, but components of the state and behavior of the
Vat-actor they are in.
Put another way, to someone coming from Smalltalk..Java, E seems like a
conventional sequential call return object language, using "." for
invocation, to which we added eventual sending "<-" to support communicating
distributed event loops. To someone coming from an actors language,
especially Joule, E seems like an actor language, using "<-" for invocation,
to which we added "." to support more complex computation within an event.
If you have access to Powerpoint 2002 or later, please step through the
animations at http://www.erights.org/talks/promises/index.html , which is
our best explanation to date of what you get when you combine the constructs
in this way.
>p.s. i am interested in porting "secure distributed actors" to the
>ruby language, which is already pure OO.
That would be great! I don't know Ruby, but so long as you explain the Ruby
we need to answer your questions as you go, I, and the rest of e-lang, would
love to help you succeed at this.
I encourage you to look at CapTP and the web-calculus as protocols you may
want to adopt, so that perhaps Rube-E vats could interoperate with secure
distributed E and Waterken objects.
Text by me above is hereby placed in the public domain
More information about the e-lang