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?'.

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

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 islocallybuffered. 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.

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.