E Priorities & Triage

[Mark S. Miller]

We're on the edge of releasing E 0.8.2, and when we do my announcement email 
will list what's new there.  But the big news of this upcoming release is 
that there is no big news, even though it took more work than many earlier 
releases.  For the kind of thing E 0.8.x has been trying to be, we're 
starting to approach "feature complete".  The work in this upcoming release 
was mostly on improving the coherence and correctness of the features we've 
already got.

In this message, I'd like to bring up a more important question.  Soon we'll 
be declaring E ready for publicity and promotion, announcing it on slashdot 
and such.  I will also be needing to find support for E -- be it a VC funded 
startup, non-profit donations, more contracting, a research lab job, or 
something else -- so I can continue doing this full time.  Hopefully the 
nature of the support will enable me to ask some of you to join me full time 
as well.

So the question is, what remaining work should be done on E before we can 
declare it that-kind-of-ready?  The most important criteria is that those 
who decide to download and play will quickly have a rewarding experience, so 
we can suck them in.  Also, is there anything about the current system 
that's just embarrassingly bad?

Here are my candidates of major items still to be done in this phase:

	More book chapters.  Specifically

		Collections
		Patterns
		Quasi-Literals
		Concurrency
		E-to-Java Binding
		others?

	Internal documentation

		The blankness of so many javadoc pages communicates 
		unprofessionalism.

	Linux install

		Many of our early adopters are here, especially when we
		announce on slashdot.  We've gotta have a clean install.

	Continual bug fixing as it comes up, of course.

	Vat creation and manipulation API.

		The only way to get true concurrency in E is to create more 
		Vats.  However, we have not defined an API by which E code 
		in one Vat creates and starts another Vat, and how that 
		code manipulates the Vat it started.  I imagine something 
		like how one KeyKOS Domain / EROS Process creates and 
		manipulates another.

		Rather than take a shortcut, for now I'm simply gonna have 
		all inter-Vat E messaging go through the full Pluribus 
		comm system, even when they're in the same JVM. Given this, 
		we've already got most of the mechanism, we've just gotta 
		define and implement an API around it.

		Without this, our concurrency story is obviously 
		incomplete, but I'd love to hear arguments that we can
		postpone it anyway.

	Updoc

		It's the only reasonable way to ensure the examples in the 
		book are accurate.

	A small number of small example smart contracts.

		Like, what's all this stuff for anyway?

	Anything else??


Here are my candidates for painfully important items that can wait till 
after this phase:

	Persistence

		Can't actually *do* any smart contracting without it

	Vat Location Service

		Once we have persistence again, we have to revive this.  
		There's also been a lot of good thinking about the firewall 
		issue, some of which will need to be implemented soon.  
		Fortunately, I saved all my notes from that meeting at 
		Bill's house.  I even know where they are after moving!

	Auditors, (see http://www.erights.org/elang/same-ref.html ) 
	the first step to 

		value-based-equality objects,
		PassByCopy Objects
		Confinement.

		All of which are next on the list once we have auditors.

	Cleansing Java

		Back in OriginalE days, Danfuzz went through the Java 
		standard libraries and determined what subset of them obey 
		capability discipline.  I need to parameterize my E-to-Java 
		binding mechanism with this information, so E code only 
		sees this subset of Java.

		We can't support mutual suspicion within an address space 
		until we do this.  The new simplified & more powerful smart
		contracting story (The Game Creation Game) requires this.

	Compiler

		Now that more of E's implementation is moving from Java 
		into E (as Danfuzz long ago recommended), the performance
		penalty for interpreting parse trees rather than compiling
		is starting to hurt.  The available of the GNU Java-to-C
		system gives hope that E may run as fast as symbolic 
		languages normally do, while still allowing us to build
		on the Java libraries.  (The interpreter would remain an 
		executable specification in pure java.)

	Debugger

		All of us have lived through dealing with languages that 
		don't yet have one.  'nuff said.

	Reasonable error diagnostics, especially in parsing.

		AFAIK, I always throw exceptions exactly when I should.  
		However, which exception I throw for what, and how informative 
		they are, needs an large overhaul.


What did I forget?  What's on the wrong list?  What should be added or 
removed?  What needs more explanation?  

Most important: What would make a difference in your choice about using the 
language?

Opinions solicited.  Thanks.



			Cheers,
			--MarkM