[antlr-interest] Re: Seperating Grammar and Actions..

John D. Mitchell johnm-antlr at non.net
Tue Jan 14 11:11:48 PST 2003


>>>>> "cintyram" == cintyram <cintyram at yahoo com> <cintyram at yahoo.com> writes:

>> I'm cool with the general idea of a stripped down IR (e.g. all looping
>> constructs collapsed into 'for' in C) but some of the CIL transforms
>> are....well scary ;-).
> ..

> Leaving the penchant for genericity aside for a moment , if we consider
> teh real world, teh reason any one would want to start writing a grammar
> is to solve an immediate problem. teh chances of extension might not be
> apparent then

Depends on the project.  Some are clearly quick and dirty to begin with
while others are clearly large, multi-use projects -- and then there's the
big gray area in-between.  :-)


> While im all for the ability to generate a tree with the parser itself,
> developing our own tree gives us more flexibility .  since we any way
> have to do multiple passes to get something done, a different set of
> actions [ lets say a different path ] taken could result in an entirely
> different application . if such a different path seems possible we should
> already have enough information to make it even easier. agian we can
> argue in two ways .. if the first tree [ir] is always generated by teh
> tool , we have a standard reference, alternatively if the ir is generated
> by us we have enough flexibility to decide and plan for what exactly
> suits our applications possibilities .

I guess that I'm missing your point(s).

Antlr currently gives you help in building your trees in the parser while
giving you the freedom to override it.  Given some of the recent bug fixes,
the flexibility has been improved.

My point is that building a useful initial AST along with any necessary
auxilliary data structures should be the goal of the parser.  [The only
other primary activity should, of course, be giving good error messages to
the user when there are errors.]


> By properly providing standard components which can still generate
> behaviour like what we have now, without a significant loss in cost , we
> can default to one standard behaviour, but by providing our own
> componetns we can extend it or over ride it .by seperating action ,
> including that of the initial tree constrution , from the grammar we
> achieve this decoupling ..  like if there are easy ways of building
> binary/m-ary trees instead of child -sibling, and appropriate tools for
> writing those tree grammars and tree walkers ..wouldnt one want to have
> an option of specifying what format of tree to be generated ?

Sorry, again I'm confused by your writing.

What does the implementation choice of direct, n-ary tree nodes versus the
current child-sibling node structure have to do with what you can achieve
with tree walkers?

I'm not saying that building an good, useful, initial AST is or should be
trivial for the vast majority of languages.  IME, trivially (nee
frivolously :-) made AST are a PITA to deal with.  I am saying that the
parser should be the bridge between the, all too often, messy token stream
and a rich, useful intial AST. Explication and normalization being the two
key structural criteria.

Take care,
	John

 

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



More information about the antlr-interest mailing list