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

[cintyram <cintyram at yahoo.com>]

> 
> 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.  :-)

yeah ;

 
> > While im all for the ability ...   plan for what exactly
> > suits our applications possibilities .
> 
> I guess that I'm missing your point(s).
> 

please excuse me if im not able to express my view properly. i am not
pointing out any deficiencies in antlr or any other tool, 
i just made a comment on an idea that struck me;  

> 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.]
> 
> 
> 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?


 if a different application requires a different processing , it would
only be a little less difficult starting with the wrongly structured
tree than starting with teh original token stream ;

i wanted to say that even the initial AST and auxilliary structures if
any are not written in stone for all possible applications that can be
based on the same parser/lexer etc .. lets look at it like this :
Let us assign the rank 0 to Lexer ,
1 to Parser ,
2 to any immediately subsequent phase [like tree walker or tree Maker]  
3 for a first pass over the tree ..

assume there are many such stages upto rank say 15 or more ..

if say rank 5 op[operation] is only to act as a bridge between the
tree output by rank4 op, and a different format expected by rank6 op ,
and it is possible to write one simple processing unit which does this
without making a tree which is any way not used .. but directly by
making a tree that is expected by rank6 op from the input to the rank4
op ; we should have an easy framework where we can do this ;

if we "brack project" this idea to the initial stages ie  rank 0 and 1, 
we find that generalisation is only possible to some extent , but by
being able to recognize and express that possibility we can have a
toolset which is more suitable for a case where the higher ranked ops
, can be replaced to achieve a different target/application ;

for example if say we start with a java compiler with 5 ranks ,
now if we replace say rank 4 and rank 5 ops with some other operations
may be three new processing units, and end up with a code analyzer,
which just detects the pattern of use of white space .. etc .. or
looks for some pattern of use of comments [ just as an example ]
if we had started out with a different ir , which makes it easier to
access the white space and comments rather than the actual code, may
be  we end up with a faster app ;

another example is if we want regular expression based syntax
highliting in the source editor, which can also act as compiler's
front end etc ..we want two sets of output one which can be used by
teh renderer and the other for the compiler.  this might be a bad
example but now im not able to come with anything better ;

again, i am sorry if i had written in a confusin way, and hope this
helps  you in understanding what i wanted to say .
please do comment ;

cheers
ram














 

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