[E-Lang] Quick Guide to Sources?

[Mark S. Miller]

At 11:51 PM Saturday 4/7/01, colin@field.medicine.adelaide.edu.au wrote:
>Hi E-guys,
>
>Is there a nice continent chunk of code somewhere which will take E and spit 
>out Kernel-E?

Continent?  Since I don't understand what that word means in this context, 
I'll act like an html browser and ignore it, hoping for the best ;).

Let's examine the following interactive (E or Elmer) session:

    ? def EParserMaker := <import:org.erights.e.elang.syntax.EParser>
    # value: <import:org.erights.e.elang.syntax.EParser>

The EParserMaker is an object whose methods correspond to the static methods 
of the EParser class.  This class is mostly automatically generated by 
byaccj (Berkeley Yacc for Java), and so has a voluminous javadoc.  But the 
static method of interest is "run" 
http://www.erights.org/javadoc/org/erights/e/elang/syntax/EParser.html#run(org.erights.e.elib.tables.Twine)
, which, in E's current operator expansions, corresponds to function call:
    
    ? def ast := EParserMaker("2 + 3")
    # value: e`2 add(3)`

This parses the provided E language string and returns the corresponding 
Kernel-E AST (or throws an exception if there's a syntax error).  The E 
command line interpreter then responds by showing the printed form of this 
AST according to its "printOn" method.  Kernel-E ASTs print in Kernel-E 
notation surrounded by " e`...` ".  The reason for this peculiar notation is 
that the easy way of expressing Kernel-E ASTs literally or quasi-literally 
is with the "e" quasi-parser, as explained on 
http://www.erights.org/elang/grammar/quasi-overview.html .  Using this 
notation, you could have simply said:

    ? e`2 + 3`
    # value: e`2 add(3)`

but only if you knew the E language string literally.



>Is there a nice continent chunk of code somewhere which will take Kernel-E and 
>spit out either:
>        1) some form of AST

The above.

>        2) the XML form you're looking at?

Not yet, as I haven't had the time.  I've been planning to convert from this 
AST form to the Minimal-XML DTD explained at 
http://www.erights.org/elang/kernel/index.html .  It shouldn't be too hard.  
See also the smallSchema proposal at 
http://www.smallstd.org/smallschema/index.html .  It's a schema language 
expressed in Minimal-XML for describing the subset of DTD info relevant for 
Minimal-XML. http://www.smallstd.org/src/org/smallschema/kernel-e-schema.xml 
is a partial example of how the Kernel-E DTD would look in smallShema.


>        3) some other not-too-arcane tree structure?

Haven't considered anything other than the ASTs we've got, and the 
Minimal-XML proposed above.  Do you have something else in mind?


>And if so are any of the above available in C or C++, or do I have to go find 
>a Java machine?

Nope, sorry.  The only relevant C or C++ code is 
http://www.erights.org/enative/enative.zip .  And as explained below it 
needs to be rewritten from C++ to C.  And it doesn't do the job you're 
asking about.


>We're looking at doing something along the lines of ENative.

That would be wonderful!  Rather than "something along the lines of", if our 
goals are compatible enough, would you consider having your project be the 
ENative project?  The only recent progress on ENative has been the 
definition of capIDL http://www.capidl.org/ for interfacing ENative to EROS 
so that E can serve as EROS's command line shell.  (Jonathan has made further 
progress on the definition of capIDL since the grammar posted there, but we 
haven't published this yet.)

In recent private correspondence I described the current thinking about 
ENative as follows:

I wrote:
>We now have a real need for a standalone ENative -- to be the shell language 
>for EROS.  As a result, the ENative plans have advanced since the web pages 
>http://www.erights.org/enative/index.html were put up, but no further 
>progress has been made on implementation.  The current plans are to rewrite 
>in C (rather than C++) in a way that works with the runtime conventions of 
>JNI, such that it could run standalone or call and be called through JNI.  
>To make the latency of accepting new E code low enough to be acceptable in a 
>command line shell, we'd compile E to bytecodes and interpret the bytecodes, 
>rather than, as you see on those pages, compile to C++.




        Cheers,
        --MarkM