E Priorities & Triage

[Marc Stiegler]

A small note, the only moment of difficulty I had bringing up E on a Linux
machine was toggling the line in the *.sh file from using the one with
semicolons to the one with colons. Colons is correct for all the unix's,
right? anyway, if you just changed the default there, I think you can just
drop E on a linux machine and have it pop to life (might want to put a
symbolic link to elmer.sh in the top-level of the unpack process, so people
can bang it quickly and easily and see it working).

There is a problem with me as a test audience, I must observe: I have become
painfully intimate with the layout of E, so what is obvious to me might not
be obvious to others :-)

--marcs

-----Original Message-----
From: Mark S. Miller <markm@caplet.com>
To: E Language Discussions <e-lang@eros.cis.upenn.edu>
Date: Sunday, April 18, 1999 2:25 PM
Subject: E Priorities & Triage


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