[antlr-interest] Re: aspectANTLR sketch

[mzukowski at yci.com]

One goal is to be able to specify cross-cutting behavior without having to
explicitly insert it everywhere.  For instance you can specify an exception
handler for any rule but to do it for all rules is rather tedious.  In the
future this will be available through a hook in the code generator.  But
right now we're talking about my prototype....

Another goal is to explore composition of grammars.  I used this rather
successfully in the noweb source for the GCC translation framework.  In
addition to being able to keep related rules from different grammars in the
same section of the noweb source, I was able to define commonly overridden
methods such as reportError() in one place and use them in many grammars.
I'm pretty happy with the noweb solution for this piece, other than the fact
that it is not a standard part of antlr and is not so easy to install.  I do
have my java noweb tangler, but still I'm interested in exploring what it
might mean to support such a feature in antlr directly.  It would be easier
to make it a standard that way.  I didn't release the GCC translation
framework noweb source because I figured that nobody would want the hassle
of the extra tool layer, learning noweb syntax, probably not having an
editor that could navigate it easily, etc.

I'm also looking for a safer way to subclass a master tree grammar and add
actions for translation projects.  I used that technique successfully in the
AREV to VB translator, but it would have added peace of mind to know that my
"grammar subclasses" were not actually altering the supergrammar.  To
explicitly add macros to the entire master tree grammar seems burdensome to
me, especially when you consider that you would then have to label
everything too.  In fact if I could designate a subclass to be only a
"semantic enhancement" that didn't alter the syntax then I'd be just as
happy.  Antlr's current preprocessing scheme precludes this option.

I think a lot of antlr users don't actually write the grammars they use.
I'd like to see things made a bit easier for them.  

I'll go take a look at attribute grammar systems.  Any favorite references?

Monty

> -----Original Message-----
> From: lgcraymer [mailto:lgc at mail1.jpl.nasa.gov]
> Sent: Wednesday, June 19, 2002 2:53 AM
> To: antlr-interest at yahoogroups.com
> Subject: [antlr-interest] Re: aspectANTLR sketch
> 
> 
> Monty--
> 
> I have the impression that attribute grammar systems implement 
> aspect-oriented programming for language processing systems, and that 
> Ter's idea for code generation also also has similarities.  
> AG systems 
> tend to look fairly primitive--more like yacc than ANTLR in terms of 
> level of useability--and have a fairly static view of attributes.  
> There is room here for building something better for use with ANTLR, 
> but the strength of aspects seem to be that they add orthogonal 
> ("cross-cutting") semantics to the inline semantics of procedural 
> programs.  (AGs add semantics to otherwise semantics-free 
> specification of syntactic structure.)
> 
> What you are suggesting for a proof-of-concept is almost 
> equivalent to 
> replacing the body of action statements with m4 macros and then 
> running m4 over the generated code, but then adds the idea of 
> implicit 
> macros.  (I'm skeptical of the value of the implicit macros:  these 
> seem more appropriate to adding orthogonal semantics, and I 
> think that 
> the explicit macros at least have the advantage of visual association 
> of semantics to syntax.)  Language-independent specification of 
> actions would be a *good thing*; is there any reason to go beyond 
> this?  What am I missing--can you clarify your goals for adding 
> aspects to ANTLR?
> 
> --Loring
> 
> --- In antlr-interest at y..., mzukowski at y... wrote:
> > Pointcuts for inserting actions:
> > 	rules
> > 		initialization
> > 		specific alternatives
> > 		finalization
> > 		exception handling
> > 		tree construction
> > 		options?
> > 	grammar
> > 		header (includes variables and methods)
> > 		options
> > extesions:
> > 	tokens:
> > 		regular tokens
> > 		literal table
> > 		tree node tokens (so called imaginary tokens)
> > 	rules:
> > 		adding alternatives
> > 
> > It seems like some concept of a grammar namespace would be 
> appropriate if we
> > are serious about composing a grammar from multiple rule sets.  
> Likewise
> > token management could improve through composition.
> 
> If you do importing at the level of grammar specification
> ("import ANTLRLexer.TOKEN_REF") then you run into the version 
> problem--what happens when ANTLRLexer.TOKEN_REF is altered in the 
> latest version?  I tend to believe that composition is best 
> handled at 
> the IDE level, not at a processing level.
> 
> > 
> > Proof of concept for some of this should be possible through a 
> preprocessor.
> > I would write:
> > 
> > 1. an antlr parser that parses .g files without actions 
> (and without 
> grammar
> > subclassing for simplicity)
> > 2. an aspectANTLR parser and weaver that would parse some sort of 
> aspect
> > syntax for recognizing the above pointcuts and would generate a .g 
> file with
> > actions for input to ANTLR.  It would also allow an 
> extension syntax 
> similar
> > to Metamorphic Syntactic Macros to extend the grammar, but wouldn't 
> have any
> > fancy analysis.
> > 
> > It wouldn't have any hooks for the code generation stuff, but would 
> at least
> > be a proof of concept for handling actions and extensions for 
> grammars.  It
> > would be nice for refactoring the GCC grammar too.  
> > 
> > Anything I'm forgetting?
> > 
> > Monty
> 
> 
>  
> 
> Your use of Yahoo! Groups is subject to 
http://docs.yahoo.com/info/terms/ 


 

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