Re: reentrant flex, bison glue

[John W. Millaway]

> I'm happy to see that.  How about this alternative implementation:
> 
>         Flex does need make an hypothesis on Bison.  But Flex
>         documents the macro YY_LEX_ARGS and Bison defines it in the
>         header file.
> 
> It seems to me that this is saner.  What do you think?  This way it is
> not named `Bison' or whatever in the Flex' option, and if something
> changes in Bison, then we can handle by ourselves the compatibility?
> And Flex does not have this big chunk.

Ok, I like the general idea, but I don't like tricky preprocessor macros to be
available to the user (there are already too many).  They make it difficult to
maintain the skeleton because the way the input is currently scanned by flex.
There's a lot of code produced by flex before we even see the user's "section
1" in the input. But section 1 is the earliest place in the code where the user
can override our preprocessor macros. This is admittedly a problem, and the fix
is not easy at all. Basically, the more freedom we have with the skeleton, the
more we can keep it clean! Also if we mistype the macro's name in the manual,
or if the user mistypes it in her code, then she's up the creek unless she is
keen on wading through the generated scanner to see what happened. Some kind of
%option might be an idea, because it can be caught at compile-compile-time
(when flex is excuted).


__________________________________________________
Do You Yahoo!?
Yahoo! Sports - live college hoops coverage
http://sports.yahoo.com/