mirror of
https://git.savannah.gnu.org/git/bison.git
synced 2026-03-23 03:03:02 +00:00
Update TODO.
* TODO (-D): is implemented. (associativity): Same precedence must have the same associativity. For instance, how can a * b / c be parsed if * is %left and / is %right? (YYERRORCODE, YYFAIL, YYBACKUP): New.
This commit is contained in:
@@ -1,3 +1,12 @@
|
|||||||
|
2008-11-10 Akim Demaille <demaille@gostai.com>
|
||||||
|
|
||||||
|
Update TODO.
|
||||||
|
* TODO (-D): is implemented.
|
||||||
|
(associativity): Same precedence must have the same associativity.
|
||||||
|
For instance, how can a * b / c be parsed if * is %left and / is
|
||||||
|
%right?
|
||||||
|
(YYERRORCODE, YYFAIL, YYBACKUP): New.
|
||||||
|
|
||||||
2008-11-10 Akim Demaille <demaille@gostai.com>
|
2008-11-10 Akim Demaille <demaille@gostai.com>
|
||||||
|
|
||||||
Formatting changes.
|
Formatting changes.
|
||||||
|
|||||||
67
TODO
67
TODO
@@ -1,5 +1,60 @@
|
|||||||
-*- outline -*-
|
-*- outline -*-
|
||||||
|
|
||||||
|
* Various
|
||||||
|
** 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?
|
||||||
|
|
||||||
|
** 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 ();
|
||||||
|
}
|
||||||
|
|
||||||
|
|
||||||
* Header guards
|
* Header guards
|
||||||
|
|
||||||
From Franc,ois: should we keep the directory part in the CPP guard?
|
From Franc,ois: should we keep the directory part in the CPP guard?
|
||||||
@@ -96,9 +151,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
|
part of %if. Akim Demaille thinks it should be in the parser, so as
|
||||||
to avoid falling into another CPP mistake.
|
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
|
** XML Output
|
||||||
There are couple of available extensions of Bison targeting some XML
|
There are couple of available extensions of Bison targeting some XML
|
||||||
output. Some day we should consider including them. One issue is
|
output. Some day we should consider including them. One issue is
|
||||||
@@ -199,15 +251,6 @@ It is unfortunate that there is a total order for precedence. It
|
|||||||
makes it impossible to have modular precedence information. We should
|
makes it impossible to have modular precedence information. We should
|
||||||
move to partial orders (sounds like series/parallel orders to me).
|
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
|
** RR conflicts
|
||||||
See if we can use precedence between rules to solve RR conflicts. See
|
See if we can use precedence between rules to solve RR conflicts. See
|
||||||
what POSIX says.
|
what POSIX says.
|
||||||
|
|||||||
Reference in New Issue
Block a user