[antlr-interest] Re: aspectANTLR sketch

lgcraymer lgc at mail1.jpl.nasa.gov
Wed Jun 19 02:52:49 PDT 2002


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/ 



More information about the antlr-interest mailing list