[E-Lang] E FAQ

[Mark S. Miller]

>6.5. How does E relate to other efforts such as E-speak, 
>            EROS, and Mozart?
>[To be answered]

We have representatives of each of these systems on e-lang.  How about it guys?


>3.2. If an E process is single-threaded, how to take advantage of
>            parallelism (e.g. on SMP's)?
>[To be answered: micro-parallelism and/or multiple vats]

What do you mean by "micro-parallelism"?  My only answer is multiple vats.


>4.1. Why are local and remote objects treated differently in E?
>[To be answered - need to justify shared state]

I'm not sure what relevance of "shared state" you have in mind for this 
question.

Abstracting differences from 
http://www.erights.org/elib/concurrency/semi-transparent.html :

* Synchrony: On one CPU, you can only do one thing at a time anyway. Between 
machines, it would waste potential parallelism.

* Latency: Local communication has no latency.  Remote has huge latency, so 
processes should avoid needing to wait on each other.

* Atomicity: Local atomicity is cheap.  Remote mutual exclusion of any kind 
should usually be avoided.

* Partial Failure: The local process is either perfect or dies as a whole. 
Therefore, within relationships local computation can be assumed to be 
perfectly reliable.  However, one machine or process can fail while another 
doesn't, or a communications failure can cause them to be inaccessible, 
causing inter-process relationships to be at best fail-stop.

* Temporal inconsistency: Within one process, time proceeds forward in lock 
step.  Between machines or processes, not only does time proceed in at best 
partial causal order, but by allowing them to make progress during times 
they can't reach each other, they can chose to make possibly divergent 
decisions they would then need to reconcile.

(Btw, an even worse problem, that can be gotten rid of at some cost:  
Restoration from previous checkpoints or backup tapes can cause one process 
to regress from the perspective of other processes.)


>4.6. What network protocol does E use?
>[To be answered]

The E protocol stack is called 'Pluribus', and currently consists of two 
working layers:


For the https-like level of protocol -- secure data pipes between vats -- E 
uses VatTP http://www.erights.org/elib/distrib/vattp/index.html .

For the Corba / Soap-like level -- messages and object references -- E uses 
CapTP http://www.erights.org/elib/distrib/captp/index.html .
  Such protocols specify a serialization system as part of their protocol.  
  E (currently at least) uses Java Serialization Streams.

(Though note that, as of 0.8.10alpha1, the CapTP layer does not yet again 
support 3vat introductions.  This should be fixed shortly.)


>4.8. Is there a reason that object mobility isn't supported?
>[Tobe answered]

If secure object mobility among mutually suspicious hosts were possible, one 
could do electronic money with no stationary issue/clearinghouse.  You would 
just make each dollar such a mobile object, and use hosting-transfer to 
represent ownership transfer.  Since no one knows how to do this, and many 
have looked, it would seem that secure mobile objects are impossible.


>5.2. What happened to the '.' in message passing syntax?
>[To be answered - recently discussed on e-lang]

Unnecessary visual noise -- juxtaposition looks cleaner.  Also, the dot 
remains reserved (in the pocket) for Bean-property syntax.

As many people have pointed out, my stance on this violates one of E's main 
design premises.  It's an unnecessary unfamiliarity for C-syntax-tradition 
programmers.  I respect this objection, and have privately experimented with 
changing my mind.  But I just can't stand what it does to the look of my 
programs.


>6.1. Is there an E IDE?
>[To be answered - no, I guess, but Emacs works pretty darn well.]

Well, as of 0.8.10alpha1, eBrowser is starting to get pretty serious as a 
development environment.  A 'DE', but not yet an 'IDE'.  We still sorely 
lack a debugger, and will for a while.


        Cheers,
        --MarkM