Re: multiple grammars/parser with common parts

[Hans Aberg]

At 13:57 +0100 2004/03/09, Thomas Lavergne wrote:
>Here is the situation. Imagine I have classes representing geometrical
>objects (spheres, rectangles,...). I have an executable Exe1 which wants
>to perform the instantiation of objects while parsing an input file with
>bison's actions. That's fine with one bison parser interfaced with
>yyparse(). Now, let's imagine I want to write another executable Exe2
>which uses part of the same grammar (and underlying classes, hence the
>same grammar actions) along with other classes and grammar rules that
>are specific to him. I do not want to duplicate the common part of these
>two grammars because it is time consumming and will soon be a pain to
>maintain ; and I do not want Exe1 to learn for the part of grammar that
>is specific to Exe2 (and vice-versa).
>The question is how can I have multiple parsers with common parts in
>their grammar (both symbolic and semantic)?

It seems me that you are merely asking how to generate two different
parsers, which happen to partly use the same grammar and actions. Then I
would suggest that you write a file that is passed through a preprocessor
(M4, perl, etc) that extracts the two .y files.

The parsing generating algorithm that Bison uses is such that one cannot
expect to generate a common core corresponding just to the common grammar
parts. And Bison does not support any feature that one can write two
grammars at once.

>In my parser file (bison.y), I am allowed to use #include, #ifdef,
>etc... so I think I can manage this by compiling twice my bison.y but
>with different prefix (-p prefix) and some #ifdef EXE1 and #ifdef EXE2
>blocks. Anyway, I would like to know if there is any other solution
>(providing that this one works: not tested)?

You can't use C preprocessor commands in the grammar part of the .y
grammar. (But grammar parts can be commented out.) So this approach would
not work.

  Hans Aberg