[antlr-interest] Aspects and ANTLR (was: Re: nice threads)

[mzukowski at yci.com]

Very interesting stuff, here are some of my thoughts on your points:

Separate grammar stuff from actions.  The way I see things now I don't want
to override behaviors by changing actions.  Instead I want to compose by
choosing actions and applying them to an action free grammar.  Obviously we
need to look at basic actions that are usually wanted such as symbol table
entry and scope management.  Those directly affect the parse through
semantic predicates.  Though I must say I'd rather see the all the code for
symbol management in one place instead of scattered throughout the code.

Intelligent composition will require some sort of sanity check to make sure
that the composition of the pieces you want don't conflict.

When I wrote the GCC translation framework in noweb I interleaved the C
parser, GCC parser, tree parser and code emitter rules together so I would
remember to update them all whenever I changed one.  I think that is a very
beneficial practice whether they are really located together in the same
file or "virtually" through the help of an IDE.


> If I want to preserve the original header, and just add 
> something to it (a
> new import, for instance, because I want to add some new 
> auxiliary methods),
> I can write something like:
> 
> ...
> header {
>    super.header();           // preserve the default header
>    import com.extra.*;       // add a new import
> }

I don't like the super.header() thing because I'm not convinced that
overriding is necessary.  Appending should be the default in my opinion, but
I haven't thought it all the way through.
 
> Alternatively, in an Aspect style:
> 
> XxxParser.header: last() { import com.extra.*;      // add a 
> new import }
 
I like that better.
> I would like to go down to token (AST) level, and I'm thinking on a
> XPath-like syntax:
> 
> /Parser/rules/"expression"/ID[3]
> 
> (to reffer the third ID of the parser rule named 
> "expression"). Although I
> would prefer '.' instead of '/' (more readable, to me).

I don't like the idea of ID[3] because it makes the whole thing fragile when
the expression rule is changed.  In fact I don't mind specifying the grammar
fragment, provided that the grammar fragment is used to match the subrule to
be modified and not specifying or modifying the grammar itself!  Grammar
modification has its place but should be separated from actions.  So
something like:

xxxParser.rules.expression: alternative("switch" expr st:statement)
{st.doSomethingInterestingHere();}

Note the ability to add labels and then use them.  Those would have to be
coalesced by an aspect weaver and aliased properly.  Also there is a fair
amount of intelligence in "matching" the grammar fragment to the
alternatives of the grammar.  

The most important thing, I think, is that if the expression rule is changed
such that ("switch" expr statement) is no longer  there, then the weaver can
complain instead of blindly overwriting as the current subclassing does, and
instead of getting confused by numerical indices into the rule.
 
> I need to think more on this; what do you think? Any feedback 
> from you will
> help me a lot.

This is fun.  How smart if your preprocessor?  Could it be extended to
handle the notation I described?

Monty
www.codetransform.com

 

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