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

cintyram <cintyram at yahoo.com> cintyram at yahoo.com
Mon Jan 13 05:55:04 PST 2003


--- In antlr-interest at yahoogroups.com, "John D. Mitchell"
<johnm-antlr at n...> wrote:
> >>>>> "Ruslan" == Ruslan Zasukhin <sunshine at p...> writes:
> [...]
> 
> > And now ANTLR can take TreeGrammar and Action files parse them. And
> > produce THE SAME output as it do now. I.e. We do not get penalty
for big
> > switch and additional indirect call.
> 
> I must be missing something...  I don't understand how that's any better
> than using e.g., a macro preprocessor.
> 
> Happy New Year,
> 		John

actually that [ macro preprocessor ] is what i had in mind for an
initial  implementation . because to generate target code in different
languages, we should be able to specify the target language
independently of the grammar. with the decoupling in place, we can use
antlr to generate target code for a given grammar in the same language
as teh action code is written in. and a grammar need not be tied up to
one language . so we can write a macro for the " language = " option
and replace it before running antlr.Tool  [ also since antlr does not
have any options specific to a given language, it should be possible ]

i dont know how any additional switch statements will result . 
if
  we follow the convention of using the rule name for the handler,
then all we need is a list of funtion prototypes to be available for
the generated source file , as it has to resolve and link to the
action functions .
else
 we have to use a map to findout which function is handling which events
endif

but  here the problem will be that we cannot write seperate funtions
for subrules, where as in antlr we can embed action , and semantic
predicates etc ..  near the rule itself .

if this is resolved, complete decoupling is achieved , and for a given
grammar we can have multiple action code modules, and some of them can
be even in compiled form [ which might be useful for commercial tools ]
so they can supply a new action module which is better etc .. 

all the problem lies in finding a way to seperate the code for
subrules  .. the initial idea i got was to substitute with macros ,
and define those macros in a different file, [may be along with the
action ] ;

when antlr.Tool is used, it should substitute names with defns, and
then proceed, or we can do it ourselves now without modifying antlr
source files , by passing the grammar and action files thru a macro
pre processor before giving them to antlr .

cheers
ram





 

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



More information about the antlr-interest mailing list