Quasi-Literals & XML

Monty Zukowski mzukowski@bco.com
Mon, 15 May 2000 10:02:36 -0700


> I haven't looked in detail, but I would guess that ANTLR
> already generates
> E-accessible Java.  The main thing to avoid is type-based
> overloading:
> multiple methods of the same name and arity that differ only
> in the types of
> their parameters.  Even these can be invoked from E, just
> more awkwardly.
> There is only one kind of Java-accessible Java that is not currently
> E-accessible: E cannot subclass Java.
>

Antlr does it's share of type-based overloading, for methods like consumeUntil()
to sync a stream to a particular token, or match() or other internal kinds of
things.  Most of the time you would not need to access these from E.  I can't
think of why you would want to subclass antlr code from E, especially not for
what you propose.

> However, notice that my proposal nowhere assumes or requires
> tree grammars.
> They would add value, but we don't need to solve this issue
> to get as far as
> what I propose.  By matching with Quasi-pattern DOM trees,
> ie, DOM trees
> with @-holes, we get the needed subset of the functionality
> of tree-grammars.

Cool!
Ok, wait, now I'm confused.  If you are going to use your own mechanism for
matching XML trees with @-holes, then what do you want antlr for again?  I
thought
you wanted to write a tree grammar like this so you could do transformations:

expr:
      mult
 |    a:expr '+' b:mult          { <apply><plus/>$a$b</apply> }
 |    a:expr '-' b:mult          { <apply><minus/>$a$b</apply> }
 ;

On re-reading your proposal, maybe you just want the ability for a parser
written in antlr to generate XML trees?

> >  making the tree grammar generate code in E or E-accessible Java
> As long as we're generating a parser whose actions are
> quasi-literal XML
> expressions rather than code, there's little need to have it
> generate E
> rather than Java.  Of greater importance: does ANTLR generate
> Java that
> follows capability discipline?  Does it forsake global/static
> mutable state,
> and does it avoid calling any implicitly-authority-granting
> methods in the
> Java libraries?  Since the job a parser needs to do is purely
> computational,
> one would hope the answer is "yes".  By generating E, we
> would be able to
> enforce that the answer is "yes", but we can start merely
> being confident of
> this answer -- but only if we are in fact confident.

Hmmm.  It does use a factory method for building trees where you provide the
class name.  So it uses reflection there, not part of capability discipline
probably...

> We would also want to have the same confidence for ANTLR
> itself.  This would
> probably involve stripping away the ANTLR-as-command logic
> (which open
> files, System.exit()s, etc) and incorporating only the
> ANTLR-engine-as-library logic.  Is there such a separation?
> Can it easily
> be found?

There is no such separation, at least it wasn't consciously engineered that way.
In fact, antlr coordinates sharing of token names between parsers and lexers by
writing and reading files.  A little refactoring of the code should do the
trick.  The grammar and analysis logic is factored into a good set of clean
objects.

> >  translating the actions into quasi notation code
>
> Do you mean "from" rather than "into"?

No, into.  If your actions are already in pure quasi notation, then maybe just
the code generator needs to make the variables you reference available in E, so
the actions can be executed in E.  Hmmm, using antlr to generate java which is
executed on the fly by the E runtime--you have a java compiler available?


> >Antlr itself has the ability to plug in new code generators,
> so you may not have
> >to wrap antlr.  Instead just implement a different code
> generator and action
> >translator.  Since E can use java classes, you can use the
> existing java support
> >classes for streams and such.
>
> This all sounds right. And it's very good news!
>
> >I'll have to investigate DOM to see where there might be
> mismatch between it and
> >ANTLR's tree model.
>
> I'd love to see your analysis.
>
> >I'd love to have this easy kind of tree transformation
> >notation in ANTLR.
>
> Thanks!  Considering how well designed ANTLR already is at
> such things, this
> is quite a complement.
>