Re: No Bison 3 in untainted macOS installs

[Hans Åberg]

> On 21 Dec 2018, at 11:32, Uxio Prego <address@hidden> wrote:
> 
> 0. Consider a Yacc parser as a way to have a well
>   documented common ground for Bison 2 and potential
>   future releases of Bison departing from Bison 2 but not
>   departing from Yacc compatibility - simply my own
>   guess on the Bison roadmap, which I don't know, so I
>   might be much wrong. I'm thinking that one can depart
>   from Bison 2 much easier than from Yacc, as there are
>   a lot more printed documentation (and non printed too)
>   about Yacc than about Bison 2.

If the generated parser is distributed with the other sources, which is fine as 
it is platform independent, then only those that want to rewrite the parser 
would need Bison, and it is possible to use the latest version.

> 1. Once hit a multithreading problem (e.g. two threads are
>   potentially wanting to parse some doc or string at a same
>   time using the non reentrant but Yacc compatible Bison
>   parser) proxy all parsing needs in a single thread, in
>   order to avoid invalid access to the Yacc compatibility
>   mode static globals.

Simplest is to use a single parse into an AST if the parse is unique and the 
thread the evaluation of that. If not a unique parse, there is the GLR parser, 
but not for C++ yet, I think. Otherwise, the Bison C++ parser is pure. (I don't 
recall if you want to switch to C++, though.)

> 2. After applying (1.) and once hit a performance issue (i.e.
>   at some point or under certain circumstances one thread
>   is not enough to handle all the parsing needs),
>   convert the Yacc compatible parser in a Bison 2.3 pure
>   parser, if `master` Bison is still compatible with Bison 2.
>   Else convert the Yacc compatible parser in a `master`
>   Bison pure parser, and then demand installs of the
>   software on macOS to upgrade to contemporary Bison,
>   ideally leaving the user the choice between a standalone
>   Bison install, a Macports install, a Homebrew install,
>   docker strategies, etc., unless in order to handle the rest
>   of dependencies of the software using Bison, it strongly
>   encourages one or several of these choices over the
>   other choices.

So if the generated parser is distributed with the other sources, this would 
not be an issue for users, only developers.

> Fortunately I can't think of any case where I could want to
> spawn or join threads inside inner C blocks of grammar
> rules. Anyway I suppose one can do this, specially if one
> such thread is joined in the same inner C block which
> spawned it.

C++11 and later versions have thread support.

https://en.cppreference.com/w/cpp/thread