Re: My plans for Bison: reentrant and pure

[Akim Demaille]

Eric,

> Le 12 févr. 2019 à 18:34, Eric S. Raymond <address@hidden> a écrit :
> 
> 2. There's a declaration-order bug that shows up when building re-entrant
> parsers; I tripped over it while working on cvs-fast-export. It's described
> here: http://esr.ibiblio.org/?p=6341

I guess you refer to this part:

> There is, however, one gotcha (and yes, I have filed a bug report about it). 
> Bison should arrange things so that all the %lex-params information is 
> automatically passed to the generated parser and scanner code via the header 
> file Bison generates (which is typically included in the C preambles to your 
> Bison grammar and Lex specification). But it does not. 
> 
> You have to work around this, until it’s fixed, by defining a YY_DECL macro 
> that expands to the correct prototype and is #included by both generated 
> source code files. When those files are expanded by the C preprocessor, the 
> payload of YY_DECL will be put in the correct places.

I don't know what bug report you are referring to.

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've written many reentrant parsers with Bison and Flex 
without the bison-bridge, I don't think it is needed.

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.

Cheers!