two (or more) lex's/yacc's in one executable

[? Polfer]

In article <1990Dec6.200944.13037 at cs.columbia.edu> leland at cs () writes:
>I have an application that requires two discrete uses of both lex and
>yacc. [...]
>I've tried this kludge:  create a header file that re-#define's all the
>names 'yyfoo' in lex/yacc set #1 to be named, say, set1yyfoo, and all
>those in set #2 to be named set2yyfoo.

Trying to redefine all of the symbols can be a real pain in the neck.  Try
to use "#define yy set1yy" or "#define yy set2yy" at the top of your
different parser files, and then have the parser files include the lex
code (catching all of the lex symbols).

>[...] code includes calls to yyless() and yywrap(), which are in the LEX
>library (-ll), the contents of which I cannot rename.  So that doesn't
>work.

The LEX library (libl.a) includes default objects for yyless, yywrap, reject,
main, and allprint (a routine used by the builtin debug code).  Each of these
routines are fairly trivial, and can be replaced by you with little effort.
For example, the yywrap code in libl.a is equivalent to the following:

    int yywrap ()
    {
        return(1);
    }

yyless is about as tough, you simply use the unput routine to push the last
few characters of yytext back onto the input stream.  Note that there is a
stated limit of 100 characters on unput (although I've observed 200).  Also,
remember that in your lex/yacc files, you must use yytext (not set1yytext)
because the macro definition will take care of the translation.  As far as
unput, input, and output are concerned, LEX usually defines these as macros
so there is no danger unless you have implemented the routines as functions
and undefined the macros.  Replacing the routines with your own will allow
you to kill the link dependancy on libl.a.

>I've also investigated GNU's replacements for these programs, flex and
>bison.  I haven't gotten to the bison documentation yet, but a
>quick look at the flex man page implies that these programs still
>have the hardcoded global symbol names.

Flex and Bison can produce code for "isolated" modules (for lack of a better
name), but Bison is from the Free Software Foundation so you need to follow
their usual conventions (your code becomes free, etc).  I'm not sure about
Flex, but I didn't think it had the same restrictions (it's from a California
University, Berkely maybe?).

    Anyway, hope the above helps!

--

Dan Polfer                             ...uunet!ingr!b29!dap!dan  (UUCP)
Intergraph Corporation                 b29!dap!dan at ingr.com       (Internet)
Huntsville, Al                         (205) 730-6154