[e-lang] Volunteering

[Darius Bacon]

"Mark S. Miller" <markm at caplet.com> wrote:
> At 03:19 AM 4/28/2004  Wednesday, Darius Bacon wrote:
> >I just added last year's C version of ENative to the CVS repository of
> >http://sourceforge.net/projects/epan
> >(it doesn't yet show up in the CVS browser
> >http://cvs.sourceforge.net/viewcvs.py/epan/epan/lib/
> >but it's at lib/csrc/e-in-c if you check it out as anonymous.) 
> >[...]
> >See lib/packrat in the same CVS repository -- some bare beginnings. [...]
> 
> WOW! This is great!
> 
> (Btw, do you mean "lib/smallcaps/csrc/e-in-c"?)

Oops, right!

> http://www.eros-os.org/pipermail/e-lang/2004-April/009741.html 
> documents the term-tree form that a PEG will parse into as of the next E 
> release. It looks to me like it would be easy to translate from that into 
> your PEG-in-E representation. Perhaps we'll have a pure-E parser generator 
> soon! Cool!

Yes, it should be trivial to convert a term-tree representation of a
PEG into a recognizer (making a parser depends on where we'd get the
semantic actions from; right now there's no convenient notation for a
parser with semantic actions, although you can build one 'by hand'
from the basic combinators).  I said I wasn't going to work on this,
but for the sake of procrastinating on my real work I've just updated
it with support for semantic actions and the remaining basic PEG
operators.  It still needs error reporting and recovery -- there's a
reasonably simple strategy described in the packrat thesis, if anyone
wants to tackle that.  (See the url in the source code.)

> >since the Smallcaps VM isn't ready to port yet.
> 
> What is the current status of Smallcaps at epan?

About the same as it's been the past N months, I'm afraid: it's a
working patch on E 0.8.22d (I believe) that can compile and run simple
programs, with compiled code able to interoperate with interpreted and
Java code.  There are several Kernel E constructs it handles
incompletely or not at all, like the such-that pattern; the next ones
I'd meant to nail down were try/catch/finally, but they're going on
the back burner since you're changing them anyway.  There are some
other loose ends to attend to, like holding on to doc comments.  I had
to make a sleazy hack in the interpreter's startup environment
building, and emailed you and Dean asking the right way to handle it,
but there's certainly no hurry about fixing that yet.  A diff of the
code against a recent E version ran into a few thousand lines, IIRC,
and at some point those are going to have to be merged (I don't know
how much of that is changes against E 0.8.22d, though -- we might get
lucky and find it's most of it).  Since I got my old setup working
again, I could move ahead without first bringing it up to date, but
that might discourage others from contributing.

What happens next is up in the air -- if anyone volunteers, it's
probably best to bring it up to date first.  I have paid work I should
be doing instead, but at some point I ought to sit down with some
paper and work out exactly what opcodes and translations we need for
the unfinished Kernel E constructs (other than the exception stuff).
Others should be able to do so as well after a moderate amount of work
understanding the current code base -- it's definitely not
release-quality but it's not too horrible either.  If my memory's not
just blocking out the horror, I mean.

In summary, the remaining jobs as I remember it:
1. Bring it up to date with the E mainline.
2. Work out the remaining details in the opcodes and translation
scheme.
3. Implement them.
4. Clean up the code and implement subsidiary features (like debugging
info and doc comments).
5. Make a full test suite and fix any bugs it turns up (I have a small
updoc suite and no known bugs not obvious in the source as FIXMEs,
etc., as far as I remember).  This should aid other implementations as
well.
6. Create an official Smallcaps specification that a C implementation
could follow. (Not on the critical path.)
7. Add some code to dump compiled code into some sort of object file,
or perhaps as C source-code arrays.
8. Translate the compiler to E, or retarget Dean's compiler, or
whatever else is most convenient to get to E-to-Smallcaps-in-E.
9. Translate the VM interpreter into C, presumably following the
E-in-C scheme.  (I probably should have followed Java naming
conventions there -- one of the reasons I never posted the code until
now.)
10. Add a JVM backend.  Oh, that was the original purpose, wasn't it? :)

And concurrently it'd be great to get more of ELib into E, of
course...

I feel kind of bad about how little I've worked on this -- I'm not
good at focusing on projects that aren't 100% mine (and sometimes not
even then).  

Darius