[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Preparing the polls
From: |
Akim Demaille |
Subject: |
Preparing the polls |
Date: |
Wed, 16 Sep 2009 15:10:53 +0200 |
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.
- Preparing the polls,
Akim Demaille <=