help-bison
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: reentrant flex, bison glue


From: John W. Millaway
Subject: Re: reentrant flex, bison glue
Date: Wed, 13 Mar 2002 10:11:42 -0800 (PST)

> The thing is, you are putting a contract onto us.  You are imposing an
> interface onto Bison, where there has never been one before. 

Aha! So that's what eating you. Why didn't you voice this concern in the first
place? Here is my defense:

1. The bison manual is a contract. Bison is expected to behave as described in
the manual.

2. The bison manual details the C API. Since bison is mature, nobody expects
the C API to suddenly change.

3. If the C API for bison _does_ suddenly change, then a lot of code will
break. Flex-generated code will just be a drop in the barrel. Ideally, we'll
fix flex to match the new bison C API, and the user should only have to
recompile.

4. The "bison glue" in flex is quite simple, and not an intrusive modification.
Flex does not suffer for this glue, and will not suffer if the glue is broken
in the future. The dependency is one-way, i.e, the flex option depends on the
bison C API, not the other way around. Bison need not concern itself with flex
impositions.


> In particular because I have still not seen what exact gain the users
> can be expect from this feature.

The gain is usability and consistency. It is a pain in the ass to glue pure
bison to reentrant flex, unless you already know how to do it. Even then, it
requires a ride through the manuals, and you wonder why the tools didn't just
do it _for_ you. The glue provides consistency with the rest of the flex API.

> What Flex functions other
> than yylex could have (could be willing to have) an access to yylloc
> and yylval?

Not Flex functions, user-defined functions. Flex may not care about yylval, but
the user does. There is no reason for flex to impose restrictions on WHERE a
user is allowed to access user-accessible variables. They are global in
non-reentrant flex, and I want to preserve that "globalness" in reentrant flex.
Here's an example where the data needs to be accessible from outside yylex:

// called by bison
int wrapper_yylex() {

    // call the real yylex
    int tok = yylex();

    // post-process the token
    switch(tok){
    case FOO:
    case BAR:
    case FUM:
        if( yyleng < 1234 )
            yylval->str[yyleng-1] = '\0' ;
         tok = FOO;
         break;
    }
    return tok;
}


__________________________________________________
Do You Yahoo!?
Try FREE Yahoo! Mail - the world's greatest free email!
http://mail.yahoo.com/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]