.Coordinated by Jonathan Rees. Last modified 28 September 2001.No longer maintained. Use the standard E documentation instead.
Thanks to Mark S. Miller, Marc Stiegler, Douglas Crockford, and Alan Karp for their contributions.
Send corrections, suggestions, questions, and answers to .
I call this a FAQ, but since I have no data on question frequency, it is really just my private list of questions about E that I imagine might be asked by a skeptical newcomer.
General
1.1. What is E?
1.2. Why is it called 'E'?
1.3. Doesn't the world have enough programming languages already?
1.4. Can't E's goals be met by an API (instead of a language)?
1.5. Is E stable?
1.6. Is E supported?
1.7. Is E free?
Capability security
2.1. What is capability security?
2.2. What advantages do capabilities have over the status quo?
2.3. I thought Java was secure. Isn't it?
2.4. If capability security is such a good idea, why
isn't it in wide use?
2.5. What if I accidentally give a capability to someone who
shouldn't have it?
2.6. How does revocation work in E?
2.7. How do I know whether my objects are protected?
2.8. If capabilities can be sent over the network, doesn't that
mean they're ultimately just strings (i.e. the characters that
get sent over the wire)?
2.9. E seems to be vulnerable to denial of service attacks,
such as long-running loops. What gives?
2.10. Is confinement really good for anything useful?
Event loop concurrency
3.1. RPC and threads are simple and intuitive.
Why does E insist on the use of an event loop?
3.2. If an E process is single-threaded, how to take advantage of
parallelism (e.g. on SMP's)?
Distributed objects
4.1. Why are local and remote objects treated differently in E?
4.2. Can I tell whether an object is remote (as opposed to local)?
4.3. How are promises different from futures?
4.4. Why do promises 'become' the object that they resolve to?
This seems confusing.
4.5. Why go to the trouble of partially ordering events?
4.6. What network protocol does E use?
4.7. How do I discover / name remote objects?
4.8. Is there a reason that object mobility isn't supported?
Language details
5.1. Why lambda-based objects, rather than classes or prototypes?
5.2. What happened to the '.' in message passing syntax?
5.3. If E is so secure, how does one get anything done at all?
Miscellaneous
6.1. Is there an E IDE?
6.2. If E is so secure, how do I debug systems written using E?
6.3. How do I use Java code from E? Doesn't Java access make E unsafe?
6.4. What is Elib?
6.5. How does E relate to other efforts such as e-speak, EROS, and Mozart?
6.6. How can I learn more?
E is a programming language designed to make it easy to write distributed programs that are correct and secure. For more information, see E in a Walnut and the erights.org web site.
Douglas Crockford writes: 'I chose E because of the progression B, C. I observed that there was no language D. I figured it was a bad luck letter, so we moved on to E. That 'E' was also the initial of Electric Communities was noticed at the time. It also tied in to our development of the Unum distributed object model.'
[To be answered, with particular reference to Python and Ruby]
An API on an IPC system can provide inter-process security. But it can't provide intra-process security, because adding an API cannot take away security holes.
ELib, the Java API that underlies E, provides the means for objects to speak to one another in a capability-secure fashion. Objects defined in the E language may only affect the world outside of themselves according to the semantics provided by ELib.
Almost. As of September 2001 it is still in beta, but E version 1.0 is under intense development and is expected to be a stable public release. It should be ready in early 2002 [???].
[To be answered; maybe mention the DARPA support?]
The code distributed with E is licensed under Mozilla-compatible licenses. According to opensource.org, Mozilla is an open-source license. According to gnu.org, Mozilla is a free software license.]
[To be answered - talk about naming, authorization, POLA. Walnut deals with this.]
[MSM: Besides the usual sources, some useful distinctions may be found at http://www.caplet.com/security/taxonomy/index.html.]
Sun claims that 'right from the beginning, the Java platform was designed to run programs securely on networks'. Java takes many steps in the direction of language-based security, such as pointer safety and garbage collection. However, as explained in E in a Walnut's 'Capability security' section, Java security is based on identities of principals, not on keys, and is so complicated that no one uses it nontrivially. It may work for confining applets, but not for more sophisticated patterns of cooperation. For an example of Java's pervasive inattention to security, see the discussion in the same section of how Java's ReadStream class fails to be secure.
[To be answered; acknowledge critics before shooting them down]
[To be answered - revocation? timeouts?]
Revocation is done in user code using a pattern such as the following. This also shows the power of lambda-based facets:
class revokerMaker(var underlying) :any {
def forwarder {
# Miranda methods other than printOn and reactToLostClient
# generally shouldn't be transparently forwarded to the underlying.
to printOn(out) {
underlying printOn(out)
}
to reactToLostClient(problem) {
underlying reactToLostClient(problem)
}
# forwards all non-Miranda methods, so this pattern should
# only be used if 'underlying' is known not to have any
# protocol that gives itself away. Therefore, this is only
# for 'Cooperative (with the underlying) revocability'.
# Uncooperative revocability requires the Membrane pattern,
# for which we eventually expect to provide a library.
delegate { underlying }
}
def revoker {
to revoke() {
underlying := null
}
# Dead-man switch: if a holder of the revoking facet is lost
# (due to a network partition), then we can no longer locally
# know that they don't wish to revoke, so revoke just in case.
# This is costly, but fails safe.
to reactToLostClient(problem) {
underlying := Ref broken(problem)
}
}
[forwarder, revoker]
}[To be answered]
[To be answered. Talk about sturdyrefs?]
[To be answered: there's nothing that can be done?]
[To be answered. Cf. especially the distinctions made by http://www.erights.org/elib/capability/dist-confine.html]
[To be answered: deadlock and races, multi-threaded hell]
[To be answered: micro-parallelism and/or multiple vats]
[To be answered - see discussion]
Yes, although you have to work at it a bit (check that the reference is resolved and not near). [blah.]
[When you 'force' a future, you might block.]
[To be answered. MSM: Enables many cool programming techniques from logic programming:
[To be answered - decent explanation in Walnut]
[To be answered]
[To be answered - SturdyRefs, perhaps?]
[Tobe answered]
[To be answered]
E's synchronous call syntax follows the lead of Smalltalk, not Simula-67. The development team decided that Smalltalk's syntax was easier to read and had less visual clutter than Simula's. In addition, one of the design goals of E is to make a language capable of working as the shell language for capability secure operating systems. E is not breaking new ground here, since traditional shell languages prefer space to punctuation.
[To be answered]
[To be answered - no, I guess, but Emacs works pretty darn well.]
[To be answered following Markm's and Norm's postings]
[To be answered]
[Answered above]
E is a language and infrastructure for secure distributed applications; e-speak provides only the infrastructure. Both E and e-speak use capability mechanisms for access control, while e-speak also has mechanisms for naming and discovery. Both E and e-speak have trusted code that mediates requests, allowing a degree of manageability not provided by systems that don't mediate, such as Jini. Unlike E, e-speak is language independent, having had programming libraries for Java, Python, C++, and Perl (in various stages of completeness) in addition to a version for document exchange programming in XML. The E language makes security guarantees that e-speak cannot. For example, an E program can be analyzed for capability confinement. [Alan Karp]
Both Mozart and E descend from FCP (Flat Concurrent Prolog), and the distributed capability security properties of both languages are directly related to the security properties FCP had (in the abstract, but not in actual implementations). [Mark Miller]
[EROS, Mozart: to be answered.]