[antlr-interest] Anyone in the whole world doing multi step tree transformation?

Loring Craymer lgcraymer at yahoo.com
Mon Jan 25 02:22:16 PST 2010


Oliver--

1.)  There are languages where semantically equivalent data--argument lists and the like--appears in different places with different syntax.  In those cases you can end up with tree grammars that radically differ from the parser grammar, but then the tree grammars can usually be kept reasonably consistent.  I happen to believe that the refactoring should be done with tool assistance (a refactoring editor) so that it might be possible to reconstruct the refactorings.  Without tool assistance, though, the consolation in these cases is that the tree grammars end up being simpler than the parser grammar.

2.)  In Yggdrasil, data structures that need to be preserved across passes are declared as "public" attributes of the grammars and propagated in the target language wrapper code that invokes each pass.

--Loring




----- Original Message ----
> From: Oliver Zeigermann <oliver.zeigermann at gmail.com>
> To: Loring Craymer <lgcraymer at yahoo.com>
> Cc: antlr-interest Interest <antlr-interest at antlr.org>
> Sent: Mon, January 25, 2010 1:00:27 AM
> Subject: Re: [antlr-interest] Anyone in the whole world doing multi step tree  transformation?
> 
> Hey, Loring!
> 
> Thanks for your help. Two questions:
> 1.) This does not help when you do major refactorings, doest it ;)
> 2.) Where do you store the information you gather in analysis? I stick
> them back into the tree or put them into (symbol-)tables. If you do so
> as well: What do you do if the tree data in tables has to be processed
> in subsequent tree transformation steps? How do you pass in the data?
> 
> Any thoughts?
> 
> - Oliver
> 
> 2010/1/25 Loring Craymer :
> > Oliver--
> >
> > Some key points:
> > 1.)  Capture semantics rather than designing tree structures.
> > 2.)  Preserve grammar structure--that is, rule a in pass n becomes rule a in 
> pass n+1 unless there is reason to do otherwise.
> > 3.)  Avoid cluttering your grammars with action code.
> > 4.)  Separate analysis passes from transformation passes.
> >
> > Follow those principles, and you'll find that rippling changes across grammars 
> is tedious, but not a real problem.
> >
> > --Loring
> >
> >
> >
> >
> > ----- Original Message ----
> >> From: Oliver Zeigermann 
> >> To: antlr-interest Interest 
> >> Sent: Sun, January 24, 2010 1:03:35 AM
> >> Subject: [antlr-interest] Anyone in the whole world doing multi step tree 
> transformation?
> >>
> >> Folks!
> >>
> >> I was just wondering if anyone except me is actually doing tree
> >> transformations using ANTLR. I use the tree transformation feature
> >> introduced in 3.1. While this does work well, it is so very hard to
> >> refactor or extend my tree structures as I have to change all my
> >> transformer stages and have no tool support to find out what to change
> >> and where.
> >>
> >> I started using heterogenous tokens with normalized children to make
> >> use of compiler type checking which helps, but does not comletely
> >> solve my issues as I still have an unchecked children list - which I
> >> need to traverse the tree using tree walkes.
> >>
> >> I was considering skipping the whole grammar driving tree
> >> transformation step, but what should I replace it with?
> >>
> >> I know of the xtext approach that uses non normalized heterogenous
> >> tokens generated from a common model shared by all transformation
> >> parts. Which seems like a good idea, however, does not seem to have a
> >> means powerful enough to do serious tree transformation.
> >>
> >> Any experiences? Hints?
> >>
> >> Thanks in advance
> >>
> >> - Oliver
> >>
> >> List: http://www.antlr.org/mailman/listinfo/antlr-interest
> >> Unsubscribe:
> >> http://www.antlr.org/mailman/options/antlr-interest/your-email-address
> >
> >
> >
> >
> >
> >



      



More information about the antlr-interest mailing list