[antlr-interest] Build Question

[mzukowski at bco.com]

One way to accomplish what you wish would be to do some preprocessing.  I'm
particularly fond of the "noweb" literate programming tool, which I used to
build the GCC grammar.  It allowed me to reuse grammar fragments and then
add my own actions.  More importantly for me it allowed me to keep related
rules in the same area of the noweb file, so my declaration rules for the
ANSI C Parser, GCC Parser, GCC tree walker, GCC tree emitter were all
together, and while debugging when I modified one rule I was right there to
make sure the other rules were changed in sync.

Antlr subclassing is most useful when there are no actions to subclass.  So
I use it for a tree grammar that I subclass with actions for specific passes
of a translator.  Subclassing a grammar with actions would be almost
useless.  In fact I would reorganize my grammars as a literate program so I
could reuse parts as I wish, it ends up being more flexible than antlr's
subclassing.

Monty

> -----Original Message-----
> From: Tiller, Michael (M.M.) [mailto:mtiller at ford.com]
> Sent: Tuesday, March 12, 2002 6:48 AM
> To: 'antlr-interest at yahoogroups.com'
> Subject: RE: [antlr-interest] Build Question
> 
> 
> A few followup comments...
> 
> I was hoping to support both Java and C++ for future 
> development.  It seems like this is impractical for the 
> following reasons:
> 
> 1) Trying to write a language independent way comment rule 
> that "eats" comments doesn't seem possible.
> 2) Perhaps for misguided reasons, I'd like to be able to add 
> "child" nodes to my AST during tree construction.  It isn't 
> clear to me how that can be done in a language neutral way.  
> It would be nice if ANTLR's tree construction shorthand were 
> extended to allow this.
> 3) The target language has to be specified in the grammar 
> (couldn't this be a command line option?)
> 4) The difficulties with trying to do grammar inheritance (see below).
> 
> This isn't really criticism (ANTLR is a great tool).  
> Consider it ideas for future releases.  Because of these 
> problems, I think I'm going to have to abandon my hope of a 
> language neutral grammar and just start plugging in my C++ code.
> 
> --
> Mike
> 
> > -----Original Message-----
> > From: Ric Klaren [mailto:klaren at cs.utwente.nl]
> > Sent: Tuesday, March 12, 2002 3:51 AM
> > To: antlr-interest at yahoogroups.com
> > Subject: Re: [antlr-interest] Build Question
> > 
> > 
> > On Mon, Mar 11, 2002 at 01:03:27PM -0500, Tiller, Michael 
> > (M.M.) wrote:
> > > So far so good I imagine (although I haven't gotten far 
> > enough to figure
> > > out if this is a good idea yet).  The problem I'm running 
> > into is that I
> > > imagine these grammars may be shared among several distinct 
> > applications.
> > > For that reason, I keep the ".g" files away from everything 
> > else.  So when
> > > I run ANTLR, the Makefile rule looks like this:
> > >  
> > >  $(ANTLR) -glib $(ROOTDIR)/base.g -o $(GENDIR) 
> > $(ROOTDIR)/base_java.g
> > >  
> > > where GENDIR is the location for the generated code and 
> > ROOTDIR is where I
> > > keep the .g files.  This way, I can generate the set of 
> > source files for
> > > each project based on the grammars.
> > >  
> > > The problem is that when you use grammar inheritance, ANTLR 
> > expands the
> > > complete grammar into "expandedbase_java.g".  Except that 
> > it actually names
> > > it "expanded$(ROOTDIR)/base_java.g" (where ROOTDIR is 
> > actually expanded).
> > > In other words, it assumes that the ".g" is in the current 
> > directory.
> > >  
> > > Any suggestions about how to avoid this problem?  I'm 
> > surprised that I
> > > can't explicitly specify the name of the expanded grammar.  
> > That would have
> > > been a nice option.
> > 
> > Been there done that. Doesn't work. It needs some serious 
> > fixing in antlr
> > to make this behave well. I already looked at it when I ran 
> > into it, it's
> > not completely easy to fix in antlr. I currently copy .g 
> > files around with
> > Make rules to get the right behaviour.
> > 
> > I personally must say that I found antlr's grammar 
> inheritance pretty
> > useless (gives to little control over what you want to 
> > override, in the end
> > you end up copying action code in a complicated way so I 
> > figured I'd better
> > copy stuff around in an easy way). YMMV though I suspect some 
> > ppl on the
> > list may have gotten nice results with it.
> > 
> > Ric
> > --
> > -----+++++****************************************************
> > *+++++++++-------
> >     ---- Ric Klaren ----- klaren at cs.utwente.nl ----- +31 53 
> > 4893722  ----
> > -----+++++****************************************************
> > *+++++++++-------
> >  Time what is time - I wish I knew how to tell You why - It 
> > hurts to know -
> >           Aren't we machines - Time what is time - Unlock the door
> >                - And see the truth - Then time is time again
> >                 From: 'Time what is Time' by Blind Guardian
> > 
> > 
> >  
> > 
> > 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/ 



 

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