Future/bison
1
0
Fork 0
mirror of https://git.savannah.gnu.org/git/bison.git synced 2026-03-09 12:23:04 +00:00
Code Issues Packages Projects Releases Wiki Activity

TODO: import from master.

Browse Source 
* TODO: Copy the current version.
This commit is contained in:
Akim Demaille
2012-04-09 15:00:12 +02:00
parent 163bb3698f
commit ff1b7a1333
1 changed files with 182 additions and 62 deletions
Download Patch File Download Diff File Expand all files Collapse all files

244
TODO
View File

@@ -1,8 +1,133 @@
-*- outline -*-
* Short term
** Variable names.
What should we name `variant' and `lex_symbol'?
** Use b4_symbol in all the skeleton
Move its definition in the more standard places and deploy it in other
skeletons. Then remove the older system, including the tables
generated by output.c
** Update the documentation on gnu.org
** Get rid of fake #lines [Bison: ...]
Possibly as simple as checking whether the column number is nonnegative.
I have seen messages like the following from GCC.
<built-in>:0: fatal error: opening dependency file .deps/libltdl/argz.Tpo: No such file or directory
** Discuss about %printer/%destroy in the case of C++.
It would be very nice to provide the symbol classes with an operator<<
and a destructor. Unfortunately the syntax we have chosen for
%destroy and %printer make them hard to reuse. For instance, the user
is invited to write something like
%printer { debug_stream() << $$; } <my_type>;
which is hard to reuse elsewhere since it wants to use
"debug_stream()" to find the stream to use. The same applies to
%destroy: we told the user she could use the members of the Parser
class in the printers/destructors, which is not good for an operator<<
since it is no longer bound to a particular parser, it's just a
(standalone symbol).
** Rename LR0.cc
as lr0.cc, why upper case?
** bench several bisons.
Enhance bench.pl with %b to run different bisons.
* Various
** Warnings
Warnings about type tags that are used in printer and dtors, but not
for symbols?
** YYERRCODE
Defined to 256, but not used, not documented. Probably the token
number for the error token, which POSIX wants to be 256, but which
Bison might renumber if the user used number 256. Keep fix and doc?
Throw away?
Also, why don't we output the token name of the error token in the
output? It is explicitly skipped:
/* Skip error token and tokens without identifier. */
if (sym != errtoken && id)
Of course there are issues with name spaces, but if we disable we have
something which seems to be more simpler and more consistent instead
of the special case YYERRCODE.
enum yytokentype {
error = 256,
// ...
};
We could (should?) also treat the case of the undef_token, which is
numbered 257 for yylex, and 2 internal. Both appear for instance in
toknum:
const unsigned short int
parser::yytoken_number_[] =
{
0, 256, 257, 258, 259, 260, 261, 262, 263, 264,
while here
enum yytokentype {
TOK_EOF = 0,
TOK_EQ = 258,
so both 256 and 257 are "mysterious".
const char*
const parser::yytname_[] =
{
"\"end of command\"", "error", "$undefined", "\"=\"", "\"break\"",
** YYFAIL
It is seems to be *really* obsolete now, shall we remove it?
** yychar == yyempty_
The code in yyerrlab reads:
if (yychar <= YYEOF)
{
/* Return failure if at end of input. */
if (yychar == YYEOF)
YYABORT;
}
There are only two yychar that can be <= YYEOF: YYEMPTY and YYEOF.
But I can't produce the situation where yychar is YYEMPTY here, is it
really possible? The test suite does not exercise this case.
This shows that it would be interesting to manage to install skeleton
coverage analysis to the test suite.
** Table definitions
It should be very easy to factor the definition of the various tables,
including the separation bw declaration and definition. See for
instance b4_table_define in lalr1.cc. This way, we could even factor
C vs. C++ definitions.
* From lalr1.cc to yacc.c
** Single stack
Merging the three stacks in lalr1.cc simplified the code, prompted for
other improvements and also made it faster (probably because memory
management is performed once instead of three times). I suggest that
we do the same in yacc.c.
** yysyntax_error
The code bw glr.c and yacc.c is really alike, we can certainly factor
some parts.
* Header guards
From Franc,ois: should we keep the directory part in the CPP guard?
From François: should we keep the directory part in the CPP guard?
* Yacc.c: CPP Macros
@@ -12,18 +137,19 @@ They should not: it is not documented. But if they need to, let's
find something clean (not like YYLSP_NEEDED...).
* Installation
* Documentation
Before releasing, make sure the documentation ("Understanding your
parser") refers to the current `output' format.
* lalr1.cc
** vector
Move to using vector, drop stack.hh.
* Report
** Figures
Some statistics about the grammar and the parser would be useful,
especially when asking the user to send some information about the
grammars she is working on. We should probably also include some
information about the variables (I'm not sure for instance we even
specify what LR variant was used).
** GLR
How would Paul like to display the conflicted actions? In particular,
what when two reductions are possible on a given lookahead token, but one is
@@ -56,7 +182,7 @@ DeRemer and Penello: they already provide the algorithm.
We should find a means to provide an access to values deep in the
stack. For instance, instead of
baz: qux { $$ = $<foo>-1 + $<bar>0 + $1; }
baz: qux { $$ = $<foo>-1 + $<bar>0 + $1; }
we should be able to have:
@@ -71,9 +197,6 @@ must be in the scanner: we must not parse what is in a switched off
part of %if. Akim Demaille thinks it should be in the parser, so as
to avoid falling into another CPP mistake.
** -D, --define-muscle NAME=VALUE
To define muscles via cli. Or maybe support directly NAME=VALUE?
** XML Output
There are couple of available extensions of Bison targeting some XML
output. Some day we should consider including them. One issue is
@@ -92,13 +215,13 @@ XML output for GNU Bison
* Unit rules
Maybe we could expand unit rules, i.e., transform
exp: arith | bool;
arith: exp '+' exp;
bool: exp '&' exp;
exp: arith | bool;
arith: exp '+' exp;
bool: exp '&' exp;
into
exp: exp '+' exp | exp '&' exp;
exp: exp '+' exp | exp '&' exp;
when there are no actions. This can significantly speed up some
grammars. I can't find the papers. In particular the book `LR
@@ -114,7 +237,8 @@ this issue. Does anybody have it?
Some history of Bison and some bibliography would be most welcome.
Are there any Texinfo standards for bibliography?
** %printer
Wow, %printer is not documented. Clearly mark YYPRINT as obsolete.
* Java, Fortran, etc.
@@ -122,19 +246,19 @@ Are there any Texinfo standards for bibliography?
* Coding system independence
Paul notes:
Currently Bison assumes 8-bit bytes (i.e. that UCHAR_MAX is
255). It also assumes that the 8-bit character encoding is
the same for the invocation of 'bison' as it is for the
invocation of 'cc', but this is not necessarily true when
people run bison on an ASCII host and then use cc on an EBCDIC
host. I don't think these topics are worth our time
addressing (unless we find a gung-ho volunteer for EBCDIC or
PDP-10 ports :-) but they should probably be documented
somewhere.
Currently Bison assumes 8-bit bytes (i.e. that UCHAR_MAX is
255). It also assumes that the 8-bit character encoding is
the same for the invocation of 'bison' as it is for the
invocation of 'cc', but this is not necessarily true when
people run bison on an ASCII host and then use cc on an EBCDIC
host. I don't think these topics are worth our time
addressing (unless we find a gung-ho volunteer for EBCDIC or
PDP-10 ports :-) but they should probably be documented
somewhere.
More importantly, Bison does not currently allow NUL bytes in
tokens, either via escapes (e.g., "x\0y") or via a NUL byte in
the source code. This should get fixed.
More importantly, Bison does not currently allow NUL bytes in
tokens, either via escapes (e.g., "x\0y") or via a NUL byte in
the source code. This should get fixed.
* --graph
Show reductions.
@@ -144,15 +268,14 @@ Show reductions.
** Skeleton strategy
Must we keep %token-table?
* src/print_graph.c
Find the best graph parameters.
* BTYacc
See if we can integrate backtracking in Bison. Charles-Henri de
Boysson <de-boy_c@epita.fr> is working on this, and already has some
results. Vadim Maslow, the maintainer of BTYacc was contacted, and we
stay in touch with him. Adjusting the Bison grammar parser will be
needed to support some extra BTYacc features. This is less urgent.
Boysson <de-boy_c@epita.fr> has been working on this, but never gave
the results.
Vadim Maslow, the maintainer of BTYacc was once contacted. Adjusting
the Bison grammar parser will be needed to support some extra BTYacc
features. This is less urgent.
** Keeping the conflicted actions
First, analyze the differences between byacc and btyacc (I'm referring
@@ -167,9 +290,6 @@ very feasible to use the very same conflict tables.
** Adjust the skeletons
Import the skeletons for C and C++.
** Improve the skeletons
Have them support yysymprint, yydestruct and so forth.
* Precedence
@@ -178,15 +298,6 @@ It is unfortunate that there is a total order for precedence. It
makes it impossible to have modular precedence information. We should
move to partial orders (sounds like series/parallel orders to me).
** Correlation b/w precedence and associativity
Also, I fail to understand why we have to assign the same
associativity to operators with the same precedence. For instance,
why can't I decide that the precedence of * and / is the same, but the
latter is nonassoc?
If there is really no profound motivation, we should find a new syntax
to allow specifying this.
** RR conflicts
See if we can use precedence between rules to solve RR conflicts. See
what POSIX says.
@@ -215,20 +326,6 @@ $<type_name>$ = $<type_name>1. I therefore think that one should implement
a Bison option where every typed default rule is explicitly written out
(same typed ruled can of course be grouped together).
Note: Robert Anisko handles this. He knows how to do it.
* Warnings
It would be nice to have warning support. See how Autoconf handles
them, it is fairly well described there. It would be very nice to
implement this in such a way that other programs could use
lib/warnings.[ch].
Don't work on this without first announcing you do, as I already have
thought about it, and know many of the components that can be used to
implement it.
* Pre and post actions.
From: Florian Krohm <florian@edamail.fishkill.ibm.com>
Subject: YYACT_EPILOGUE
@@ -260,6 +357,29 @@ to bison. If you're interested, I'll work on a patch.
* Better graphics
Equip the parser with a means to create the (visual) parse tree.
* Complaint submessage indentation.
We already have an implementation that works fairly well for named
reference messages, but it would be nice to use it consistently for all
submessages from Bison. For example, the "previous definition"
submessage or the list of correct values for a %define variable might
look better with indentation.
However, the current implementation makes the assumption that the
location printed on the first line is not usually much shorter than the
locations printed on the submessage lines that follow. That assumption
may not hold true as often for some kinds of submessages especially if
we ever support multiple grammar files.
Here's a proposal for how a new implementation might look:
http://lists.gnu.org/archive/html/bison-patches/2009-09/msg00086.html
Local Variables:
mode: outline
coding: utf-8
End:
-----
Copyright (C) 2001-2004, 2006, 2008-2012 Free Software Foundation, Inc.