[antlr-interest] Re: ANTLR 3.0 question about common actions

thrutchy eric_mahurin at yahoo.com
Wed Jul 28 15:13:57 PDT 2004


--- In antlr-interest at yahoogroups.com, Terence Parr <parrt at c...> 
> So, the main question is: how can we make standard actions in order to 
> avoid retargeting issues and yet allow for free-form actions, 
> especially those that predicate standard actions?

I think this is a worthy goal.  The thing I don't like about it is
that you have to come up with a new psuedo-language and your users
have to learn it.

I'm not going to downplay this and the need for enhancing the ANTLR
grammar, but...

I would kind of like the ability to go in the complete opposite
direction: express the complete grammar directly in the target
language in a nice concise manner.  The reason is that I quite
regularly have to go figure out exactly what code ANTLR is generating
to a) find out what is really going on, or b) figure out how to get
around some limitation.  I think this might be possible if you have a
clean enough API underneath.  I did something like this using objects
in Perl a few years ago and it worked out quite well, but it wasn't
too sophisticated.  I haven't thought through this all the way, but
here's what I was thinking:

* Parser/lexer rules/sub-rules would be objects.  All of these would
belong to a superclass (or interface) - I'll call it "Syntax" for now.

* Some of the more generic Syntax sub-classes might be LoopSyntax:()*,
AlterationSyntax:(|), ConditionalSyntax:()?, IgnoreSyntax:()!,
CodeSyntax:{}, SequenceSyntax:() (),  etc.

* You'd just use new to create a new Syntax object:

Syntax mexpr = new SequenceSyntax( atom, new LoopSyntax( new
SequenceSyntax( STAR, atom) ) );

where atom and STAR would be previously defined Syntax's.  I'm not
sure how recursion would work at this point.

* Some of the basic methods might be:
  - parse/read (optionally generating a tree or stream)
  - write from tree or stream
  - lookahead
  - check for ambiguities

One of the disadvantages I see immediately is ANTLR's ability to
detect ambiguities at compile time.  I'm not sure how that would be
best handled.

What do you think?

Eric



  




 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/antlr-interest/

<*> To unsubscribe from this group, send an email to:
    antlr-interest-unsubscribe at yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 



More information about the antlr-interest mailing list