Re: My plans for Bison: reentrant and pure

[Akim Demaille]

Hi Eric,

> Le 13 févr. 2019 à 17:33, Eric S. Raymond <address@hidden> a écrit :
> 
> Akim Demaille <address@hidden>:
>> I don't use Flex's bison-bridge, and I don't recommend it.  Unfortunately it 
>> was designed independently of Bison, and it kind of commits us to things we 
>> don't didn't design.
> 
> I would by this, except that %lex-params in implemented by *Bison*.

Yes, since it needs to know what argument it must pass to yylex.
I don't understand what you are trying to say here.

>  It therefore
> could put the right YYDECL in te generated header. It doesn't - that's the 
> bug.

Well, that's a feature you would like, not exactly a bug.  It also means
that Bison will force the name of the arguments in yylex.  It also means
that Bison must decide what is the return type of yylex, which currently it
does not know.  Some people pay enough attention to stick to yytokentype, while
others keep on returning characters, so int is more appropriate.

My point is that if Bison emits YY_DECL (which, again, would bind it to
Flex, which it does not so far), then some people would probably want
something different, so we will have to provide escape mechanisms.  I'm
not sure it will make things actually simpler: more things will have to
be learned.

That's also why we don't prototype yyerror, which some people would also
argue is a bug.  But they are free to make it variadic if they use it
this way in their scanner for instance.  Should it return a void?  Or
an int?  Sometimes it's very handy to know how many characters were
printed.


>> I've written many reentrant parsers with Bison and Flex without the 
>> bison-bridge, I don't think it is needed.
> 
> I have not found documentation of how to write a reentrant parser without
> the bridge.  Does any exist?

I don't know, but I could improve examples/c/lexcalc to show that.


>> Wrt YY_DECL, well, nothing in Bison is specific about Flex.  We don't 
>> require it, we don't rely on it, so we leave to the user the choice of her 
>> declaration of yylex.  We could generate YY_DECL, but it was never suggested 
>> so far.
>> 
>> There is an example of a reentrant calculator on top of flex/bison in 
>> examples/c/lexcalc.
> 
> You later note that this example is pure but not re-entrant.
> 
> I still think this is a Bison bug.

I still think this is a feature you would like to have :)  Do you
agree that defining YY_DECL might actually be a problem for some users?
If only I could declare the signature of yylex, in the sense of the
types; but no, I must decide for the users what the name of their
arguments.  YY_DECL is not a signature, it's exactly how the function
will be defined.

You might be right that everything will be right and I'm worrying
uselessly.  But when it comes to changing the API of something like
Bison, I don't feel confortable.