Re: multiple grammars/parser with common parts

[Laurence Finston]

For my project (GNU 3DLDF), I'm using CWEB for the Bison and Flex input files,
as well as for the C++ source files.  I'm doing it for other reasons, but I
believe you could solve your problem by using CWEB's `@(<filename>@>' command,
which makes it possible to write code to other files.  For example, you could
put a rule into a section called `@<Handle rectangle@>'. Then, you could
write:

@
@(parser_a.y@>=
@<Handle rectangle@>

and 

@
@(parser_b.y@>=
@<Handle rectangle@>

You could just use address@hidden' to write the output for one of the parsers to
`<filename>.c' and rename it after ctangle generates it.

You'll need to use the address@hidden ... @>' command for the Bison code that 
is not
valid C or C++, and to write a shell script or something similar to remove the
comments and `#line' commands from `parser_a.y' and `parser_b.y'.

If this idea appeals to you and you need more information, please let me know.

Laurence Finston
GNU 3DLDF maintainer
http://wwwuser.gwdg.de/~lfinsto1

-------------------
> Hi all,
> I think I can now figure out how to write grammar files and use the 
> semantic actions to create my objects with specified arguments. However, 
> I have a question  more on the conception point of vie of complex 
> packages using  bison/flex:
> 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)?
> 
> 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)?
> 
> Thanks for reading me and proposing your ideas.
> Thomas
> 
> 
> 
> _______________________________________________
> address@hidden http://mail.gnu.org/mailman/listinfo/help-bison
> 
-------------------
> Hi all,
> I think I can now figure out how to write grammar files and use the 
> semantic actions to create my objects with specified arguments. However, 
> I have a question  more on the conception point of vie of complex 
> packages using  bison/flex:
> 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)?
> 
> 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)?
> 
> Thanks for reading me and proposing your ideas.
> Thomas
> 
> 
> 
> _______________________________________________
> address@hidden http://mail.gnu.org/mailman/listinfo/help-bison
>