Preparing the polls

[Akim Demaille]

I have constant demand for Bison 2.4.2 (from a colleague who is  
sitting a few meters away from me ;), so let's move forward.  I hoped  
that 2.4.2 would have an updated exception clause, but it seems we'll  
have to do that in 2.4.3, or maybe 2.5.

Joel and I would like to include in the NEWS file some polls about  
existential questions of ours.  I'm starting with some of the items I  
remember about, there are probably more to address.

I don't know how we should invite the readers to answer.  The mailing  
lists is probably not a proper medium.  In my ancient Autoconf days, I  
remember adding a message suggesting to send information to some  
mailing list, and there were *many* such messages, way too many for us  
to handle all them.  Is there any free place to make polls?  Something  
the FSF likes?  I saw nothing on Savannah.  Maybe some wiki would  
suffice?

So, some of the questions we have.  Joel, please feel free to make  
whatever change you feel.

* Drop K&R support in generated parsers.
POSIX Yacc seems to suggest that generated parsers should be in C99:

 The C source code and header file shall be produced in a form suitable
 as input for the C compiler (see c99).
 (http://www.opengroup.org/onlinepubs/009695399/utilities/yacc.html)

Currently Bison generates K&R Yacc-like parsers.  We would like to  
change this to at least C90.  What is the most ancient C standard you  
think Yacc-like parsers should support :
  [ ] I *need* KnR parsers
  [ ] C90
  [ ] C99


* Move the implementation of Bison from C90 to C99
Current versions of Bison are *mostly* written in C90, but some  
components are already written in C99.

  [ ] C90
  [ ] C99

We are also considering using C++ in the future to implement Bison.   
These changes are internal only and do not affect anything visible to  
the user.  The only issue is the availability of a C++ compiler on  
your architecture if you still get packages from source tarballs.

  [ ] C++ is fine
  [ ] don't use C++


* Availability of the parse params in the %printer and %destructor

As written today the symbol printers and destructors provide the user  
with access to the user-defined parse parameters.  Ongoing changes, in  
particular in the C++ parser, indicate that it would be more useful to  
support a standalone type for symbols, with their own printer  
(operator<< in C++ parlance) and destructors.  In that case, providing  
%printer and %destructor with the %parse-param is a nuisance: the  
symbols cannot be printed nor destroyed "alone", the %parse-params are  
needed.

This is believed to be a flaw in the original design of %destructor  
and %printer.

Can we remove the access to the parse-params in the %printer and  
%destructor?
  [ ] yes, in all the cases (C/C++/Java, GLR or not).
  [ ] yes for C++, but I need this in Yacc parsers.
  [ ] no, do not remove this feature, I need it in C++ too.