Ee Language

An ObjectCapabilityLanguage with the WikiUnFriendlyName E.

E is "the secure distributed pure-object platform and PeerToPeer ScriptingLanguage for writing Capability-based Smart Contracts" (contracts expressed as programs, where the logic of the program's execution helps enforce the terms of the contract. See http://www.erights.org/smart-contracts/ .)

E is a BigIdea language, the big idea being CapabilityComputing. E also implements distributed capability computing, which is where things get interesting - your program can safely interact with remote E programs. The implementation enforces the above constraints securely: it ensures (by the use of cryptography in the distributed case -- see DistributedObjectCapabilityModel) that the rules cannot be violated. Lastly, E is specified to support (but at present does not implement) OrthogonalPersistence and 'AutomaticMobileCode?'.

EeLanguage is descended from JouleLanguage -- see also http://www.erights.org/history/overview.html . Like Joule, E belongs to the family of ActorLanguages. It supports synchronous method calls (like most OO languages) as well as the asynchronous calls normally associated with the ActorsModel.

Money in 21 lines of code: http://www.erights.org/elib/capability/ode/ode-capabilities.html

The reference implementation of E is currently implemented in JavaLanguage, and programs written in E can use most of Java's libraries.

There is a current project to run E code on the SqueakSmalltalk VirtualMachine, called Ee On Squeak: http://www.google.com/search?q=%22E-on-Squeak%22 (not to be confused with SqueakEe)

As an experiment, it has been suggested to use this Wiki to discuss E development issues -- see below.

[But also see WalledGardens. E language is very cool, but keep the E stuff on this page, or start an E wiki elsewhere]

I am finding the 'eventual' sends very interesting, as they return promises [PromisePipelining]. It's not quite like promises in SchemeLanguage, but more in the asynchronous sense of, when the send arrives to that object, it will do as the message says, even an eventual creation returns an immediate promise of that object so you can send eventual messages. There's a try-catch mechanism for this called when-catch, which is the only part on the program that waits until the promise is resolved (either remotely or locally). This prevents deadlocks, very interesting... -- DavidDeLis

(Besides being wiki-unfriendly this name is also GoogleHostile?, not that C [CeeLanguage], C++ [CeePlusPlus], PL/I [PliLanguage], Icon [IconLanguage] or TOM [TomLanguage] are any better in this respect...)

Open E development issues below:

E-like asynch I/O

EeLanguage needs to replace its current I/O API with a non-blocking one. The non-blocking API should be designed according to the principles of E's eventual-send messaging style.

The thread root is http://www.eros-os.org/pipermail/e-lang/2002-May/006517.html

The dangling end is http://www.eros-os.org/pipermail/e-lang/2002-June/007083.html

Is there some concrete proposal for an API to comment on?

Yes: http://www.erights.org/elib/concurrency/eio/

http://www.erights.org/elib/concurrency/eio/obtaining.html says

The sched parameter says how the operation should be scheduled:

NOW - The operation is performed immediately, whether or not sufficient elements are ready. [...]
WAIT - Warning: may block the vat and cause deadlock. If the operation can succeed immediately, it is performed immediately. [...]
LATER - Registers a claim for the next atLeast..atMost elements, and returns a promise for them.

These should be considered different primitives, not variations of the same primitive. IIUC, E has a naming convention for methods that return promises, and I think it should also have one for methods that can (intentionally) block. Methods that have one of several concurrency behaviours depending on their parameters arguably should not be encouraged.

This is part of the motivation for providing the convenience methods. However, currently, we have no convenience methods for the WAIT case; perhaps we should? Perhaps we should have "readNow", "readWait", and "readLater"? (This is especially appealing because the current "read" really means "readNow"; whereas someone coming from the C tradition may very well expect "read" to mean "readWait".)

Even if we introduce further convenience methods, your question remains: should we split the obtain primitive up into more simpler primitives according to their return type? The problem with this argument is knowing when to stop. ELEMENTS vs STATUS also makes for different return types -- making for 6 primitives instead of one.

Also, the OutStream design doesn't seem to be sufficient to provide proper backpressure on the producer. The pending messages sent to the OutStream will act as an unlimited buffer, so the producer's vat may run out of memory if it sends a lot of data faster than it can be consumed. One way of fixing this is for a client of an OutStream to be able to tell how much data is locally buffered. There probably also needs to be a variant of 'write' that returns a promise when the amount of local buffered data has fallen below a threshold.

You may have missed http://www.erights.org/javadoc/org/erights/e/elib/eio/Stream.html#whenAvailable%28int,org.erights.e.elib.base.Thunk%29

The intention of whenAvailable/2 is to enable just this kind of cooperative backpressure. It doesn't do what you're suggesting (it doesn't tell you how much is locally buffered), but does it tell you what you need? Does it address your concern?

What issue tracking software should we use?

Current candidates are Wiki, The software used by RubyGarden, and Roundup.

News: We now have a Roundup at http://lambda.sieve.net/cgi-bin/roundup.cgi/demo/

Many thanks to Ka-Ping Yee and Steve Jenson!

The thread root is http://www.eros-os.org/pipermail/e-lang/2002-June/007069.html

The dangling end of the e-lang thread is http://www.eros-os.org/pipermail/e-lang/2002-June/007084.html

See CapabilitySecurityModel, ObjectCapabilityModel, ObjectCapabilityLanguage, ActorLanguages, ActorsModel, DistributedObjectCapabilityModel

CategoryProgrammingLanguage