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

[Mark Miller]

At 12:19 PM 7/23/2004  Friday, zuzu wrote:
>ok, fine.  are the language syntax and idioms untainted by java's
>syntax and idioms somewhere?

No, the syntax and idioms are definitely tainted, on purpose. If we think of 
Joule as an exercise in pure technical design, E is Joule's essence 
repackaged for marketing purposes. Having participated in the design of pure 
systems that failed to be adopted, my mission on E is to compromise as 
needed on everything that doesn't matter -- such as whether the surface 
syntax uses curly braces -- in order to get adoption of the issues that do 
matter -- such as distributed actor-based capability secure computing.


>my questions of whether E relies on "data flow" (typical of actor
>languages) rather than "control flow" (typical of most other
>languages) and whether E is "pure actor" or not, still remain.

The "eventual" part of E (the inter-turn computing model, held together by 
eventual sends) supports data-flow better than actors conventionally do, 
because of the use of promises rather than continuation passing. But, like 
actors, a message send will convey unresolved arguments to a recipient. As 
with Actor futures, the built-in data flow waits only for the recipient to 
become resolved.

In one crucial way, E's inter-Vat inter-turn computing model goes beyond 
actors: E's semantics admits the possibility of partition (network 
disconnect), makes it visible to the program, and provides abstractions so 
that programs can robustly react to the occurrence of partition. It's hard 
to exaggerate the importance of this issue.


-- 
Text by me above is hereby placed in the public domain

        Cheers,
        --MarkM