[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: reentrant flex, bison glue
From: |
Akim Demaille |
Subject: |
Re: reentrant flex, bison glue |
Date: |
18 Mar 2002 19:15:44 +0100 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) |
>>>>> "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.
- Re: reentrant flex, bison glue, (continued)
- Re: reentrant flex, bison glue, Akim Demaille, 2002/03/12
- Re: reentrant flex, bison glue, John W. Millaway, 2002/03/12
- Re: reentrant flex, bison glue, Akim Demaille, 2002/03/12
- Re: reentrant flex, bison glue, John W. Millaway, 2002/03/13
- Re: reentrant flex, bison glue, Akim Demaille, 2002/03/13
- Re: reentrant flex, bison glue, John W. Millaway, 2002/03/13
- Re: reentrant flex, bison glue, Akim Demaille, 2002/03/14
- Re: reentrant flex, bison glue, John W. Millaway, 2002/03/14
- Re: reentrant flex, bison glue, Akim Demaille, 2002/03/18
- Re: reentrant flex, bison glue, John W. Millaway, 2002/03/18
- Re: reentrant flex, bison glue,
Akim Demaille <=
- Re: reentrant flex, bison glue, John W. Millaway, 2002/03/18
- Re: reentrant flex, bison glue, John W. Millaway, 2002/03/18