[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