darius at accesscom.com
Wed Apr 28 06:19:50 EDT 2004
"Mark S. Miller" <markm at caplet.com> wrote:
> At 05:22 PM 4/27/2004 Tuesday, James Graves wrote:
> >Well, I'm sending this message to volunteer my help for E, and I'm not
> >sure what would be best for me to do.
> * ENative http://www.erights.org/enative/
> * An E-to-Smallcaps translator + a Smallcaps interpreter written in C or C++.
> This last could be an extension to ENative, or could be something written to
> CNI (Cygnus Native Interface) conventions, to live alongside ELib compiled
> through GCJ.
I just added last year's C version of ENative to the CVS repository of
(it doesn't yet show up in the CVS browser
but it's at lib/csrc/e-in-c if you check it out as anonymous.) It's
still missing a feature or two from the C++ (the method-lookup caching
is all I remember as lacking), and I'd wanted to polish it up at least
a little before releasing -- don't have time now. It does go further
in some other ways, including a Lispy interactive-testing minilanguage
since the Smallcaps VM isn't ready to port yet.
The same CVS has MarkM's original C++ with a few tweaks by me; I would
stick to C since C++ exceptions are too expensive to use for E
nonlocal exits, and C++'s other features don't really pay for its cost
> 2) Packrat parsing is sufficiently simple, even while being more
> expressive than any of those above, that it could make sense to write a new
> parser generator in E. Unfortunately, a packrat parser, though it has
> the same complexity measure as a yacc generated parser (linear time),
> is reported to be significantly slower.
See lib/packrat in the same CVS repository -- some bare beginnings. I
don't have time to work on this either right now, but if anyone wants
commit access, just ask.
More information about the e-lang