Re: reentrant flex, bison glue

[Akim Demaille]

>>>>> "John" == John W Millaway <address@hidden> writes:

>> 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.

John> Ok, I like the general idea, but I don't like tricky
John> preprocessor macros to be available to the user (there are
John> already too many).  

I agree.  I'm not referring to this.

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

I don't understand what you are referring to.  I'm talking about
having Bison export the prototype under which it is going to invoke
yylex.  Or a subpart of the prototype, since you mean to use it to
store some additional members in the reentrant-struct.


>> Maybe you'll think I'm dishonest in the following sentence, but...
>> I don't see where Bison mentions Flex and binds the Flex community
>> with the following prototypes.

John> They are from the bison manual! 

Show where Bison binds *Flex*.  We do not bind Flex in anyway.  We
have not engaged your name in our productions.

Stated another way: had the option not named bison-foo, I would have
kept quiet.