--*- outline -*-
-
* Short term
+** Variable names.
+What should we name `variant' and `lex_symbol'?
+
** Use b4_symbol in all the skeleton
-Then remove the older system, including the tables generated by
-output.c
+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
** bench several bisons.
Enhance bench.pl with %b to run different bisons.
-** Use b4_symbol everywhere.
-Move its definition in the more standard places and deploy it in other
-skeletons.
-
* Various
+** Warnings
+Warnings about type tags that are used in printer and dtors, but not
+for symbols?
+
** YYPRINT
glr.c inherits its symbol_print function from c.m4, which supports
YYPRINT. But to use YYPRINT yytoknum is needed, which not defined by
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:
** YYFAIL
It is seems to be *really* obsolete now, shall we remove it?
-** YYBACKUP
-There is no test about it, no examples in the doc, and I'm not sure
-what it should look like. For instance what follows crashes.
-
- %error-verbose
- %debug
- %pure-parser
- %code {
- # include <stdio.h>
- # include <stdlib.h>
- # include <assert.h>
-
- static void yyerror (const char *msg);
- static int yylex (YYSTYPE *yylval);
- }
- %%
- exp:
- 'a' { printf ("a: %d\n", $1); }
- | 'b' { YYBACKUP('a', 123); }
- ;
- %%
- static int
- yylex (YYSTYPE *yylval)
- {
- static char const input[] = "b";
- static size_t toknum;
- assert (toknum < sizeof input);
- *yylval = (toknum + 1) * 10;
- return input[toknum++];
- }
-
- static void
- yyerror (const char *msg)
- {
- fprintf (stderr, "%s\n", msg);
- }
-
- int
- main (void)
- {
- yydebug = !!getenv("YYDEBUG");
- return yyparse ();
- }
-
** yychar == yyempty_
The code in yyerrlab reads:
if (yychar <= YYEOF)
- {
- /* Return failure if at end of input. */
- if (yychar == YYEOF)
- YYABORT;
- }
+ {
+ /* 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
* 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
find something clean (not like YYLSP_NEEDED...).
-* Installation
-
* Documentation
Before releasing, make sure the documentation ("Understanding your
parser") refers to the current `output' format.
* 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
* Extensions
-** Labeling the symbols
-Have a look at the Lemon parser generator: instead of $1, $2 etc. they
-can name the values. This is much more pleasant. For instance:
-
- exp (res): exp (a) '+' exp (b) { $res = $a + $b; };
-
-I love this. I have been bitten too often by the removal of the
-symbol, and forgetting to shift all the $n to $n-1. If you are
-unlucky, it compiles...
-
-But instead of using $a etc., we can use regular variables. And
-instead of using (), I propose to use `:' (again). Paul suggests
-supporting `->' in addition to `:' to separate LHS and RHS. In other
-words:
-
- r:exp -> a:exp '+' b:exp { r = a + b; };
-
-That requires an significant improvement of the grammar parser. Using
-GLR would be nice. It also requires that Bison know the type of the
-symbols (which will be useful for %include anyway). So we have some
-time before...
-
-Note that there remains the problem of locations: `@r'?
-
-
** $-1
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:
* 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
** %printer
Wow, %printer is not documented. Clearly mark YYPRINT as obsolete.
-** %define assert
-
* Java, Fortran, etc.
* 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.
* 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, 2002, 2003, 2004, 2006, 2008 Free Software Foundation,
-Inc.
+Copyright (C) 2001-2004, 2006, 2008-2012 Free Software Foundation, Inc.
This file is part of Bison, the GNU Compiler Compiler.
projects / bison.git / blobdiff