[e-lang] E is data-flow, not control-flow, correct?
markm at caplet.com
Sat Jul 24 18:01:32 EDT 2004
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
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
More information about the e-lang