Re: Bison/flex compatibility revisited

[Bruce Lilly]

John wrote:
> > No, there is *no* use of the flex API in the .y file.
> > The *only* use of flex/lex API in y.tab.c is the
> > bison/yacc-generated call to yylex().
>
>
> Calling yylex() constitutes use of the flex API.

Yes, as I clearly stated. But that use is in y.tab.c
and _*NOT*_ in the .y file.

> If you change the
> flex prefix, then the API changes, namely yylex() becomes foolex().
> The compiled y.tab.o will not link and must be edited/rebuilt to
> reflect the new flex API.

Yes, I did state that y.tab.c would have to be recompiled.  But
there's no point in running bison again on the .y file, since
bison *always* generates calls to yylex() in y.tab.c.  So your
dismissive statement "Your Makefile dependencies are incorrect"
was itself incorrect.

>  I'm trying to explain to
> you the point of the prefix, which is to place flex code in a
> different namespace -- not the "yy" namespace.

In what way does the existence of several dozen #undef yy*
directives *not* already infringe on the yy "namespace",
regardless of what prefix has (or has not) been specified?

> Imagine if flex generated foolex() directly, instead of by using
> "#define yylex foolex".  There would be no yylex().

In that case the flex output isn't going to work well with
bison, yacc, byacc, etc., all of which call yylex().  My
point is that since *only* flex "knows" what prefix it is
using, flex should generate and expose the renaming macros
that enable the flex-generated code to work with bison, etc.
Moreover, #undef yylex already infringes on names prefixed
with yy; #define yylex foolex is no worse in principle, and
in practice is necessary to get flex-generated code to work
with any parser if the entry point is renamed.  Currently
flex does generate the renaming macro as well as the
declaration, and that is A Good Thing, but flex then proceeds
to undef yylex (etc.) which has already been infringed upon;
that means that (currently) the hapless user has only a few
options:
1. expose everything to get the macros related to the prefix
2. manually edit the y.tab.c or .y file to place a duplicate
   set of renaming macros *after* the inclusion of the flex-generated
   header file (*before* it doesn't work since flex infringes
   on the yy "namespace" by undef'ing yylex etc.)
3. manually edit the y.tab.c file to change yylex etc.
Clearly, #1 involves the least upheaval associated with
changing a prefix (*only* the %option prefix in the .l file
needs to be manually changed).