[antlr-interest] ANTLR 3.0 tree construction proposal

Loring Craymer Loring.G.Craymer at jpl.nasa.gov
Tue Feb 1 20:38:48 PST 2005

> -----Original Message-----
> From: John D. Mitchell [mailto:johnm-antlr at non.net]
> Sent: Tuesday, February 01, 2005 7:17 PM
> To: Loring Craymer
> Cc: ANTLR Interest
> Subject: Re: [antlr-interest] ANTLR 3.0 tree construction proposal
> >>>>> "Loring" == Loring Craymer <Loring.G.Craymer at jpl.nasa.gov> writes:
> >>>>>> At 03:24 PM 2/1/2005, John D. Mitchell wrote:
> [...]
> > (C) Tree surgery
> >> Moving beyond the simplistic cases in (A), all of the interesting work
> >> being done in tree tranforms is real surgery of the tree.  I.e.,
> >> transformations which take place across a number of rules working in
> >> conjunction.
> > I have support for that hidden in 2.8--I haven't tested it (at the
> > grammar level; I used JUnit when developing the support classes), but am
> > not happy with my current syntax.  We talked about using attributes for
> > that at the cabal, and that has possibilities.  One of the big problems
> > is that this adds to the complexity of analysis for tree grammar
> > generation--does the calling chain go through ()?, ()*, ()+, and is a
> > tree fragment always passed into an insertion point?  That can be messy.
> Sorry for being dense (it's been a long week :-) but... If the fragments
> are in dynamic attributes, what's the analysis problem?

Each insertion point ends up defining a rule; the trick is to then find all
of the possible insertions, their relationships (if you insert bar after
foo, for example, or if bar and foo are alternative inserts), and account
for the optional [ ()? ] and looping [ ()* or ()+ ] constructs that enclose
the insert sources so that they can be reflected in the insertion point
rule.  I think that I understand the algorithm well enough to implement it
in two or three months of solid effort.

> >> (D) Error handling
> >> You haven't gone into how the error handling would work with this.
> > Eewwww.  You would open _that_ can of worms!
> :-)
> AFAIAC, if we can't do high-quality error handling (detection,
> logging/notification, and recovery) then whatever we're doing is wrong.

A key point:  with automatically generated tree grammars, ANTLR errors can
only occur in the lexer or parser.  Even if Paul Lucas' idea of propagating
error trees is adopted, we can still handle that.  So the problem is one of
what error-handling support, if any, is provided to users for their use.


> Thanks,
> 	John

More information about the antlr-interest mailing list