[e-lang] E is data-flow, not control-flow, correct?

[Mark Miller]

At 11:36 PM 7/22/2004  Thursday, zuzu wrote:
>please forgive my ignorance, i'm new to E, though i'm reading through
>the walnut.

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 
without compromise.

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

        Cheers,
        --MarkM