diff options
author | Akim Demaille <demaille@gostai.com> | 2009-09-17 09:41:21 +0200 |
---|---|---|
committer | Akim Demaille <demaille@gostai.com> | 2009-09-17 09:43:23 +0200 |
commit | 5ad90d528dc5feedb0c1d8afe82719440ec17217 (patch) | |
tree | 38e6854d19c41383464980cd518e576ff53d8931 /TODO | |
parent | a6ca4ce2292277b4af21b5069bded9c73341d23a (diff) | |
download | bison-5ad90d528dc5feedb0c1d8afe82719440ec17217.tar.gz |
todo: short term
* TODO (syntax_error, variable names): New.
Diffstat (limited to 'TODO')
-rw-r--r-- | TODO | 22 |
1 files changed, 22 insertions, 0 deletions
@@ -1,6 +1,28 @@ -*- outline -*- * Short term +** Use syntax_error from the scanner? +This would provide a means to raise syntax error from function called +from the scanner. Actually, there is no good solution to report a +lexical error in general. Usually they are kept at the scanner level +only, ignoring the guilty token. But that might not be the best bet, +since we don't benefit from the syntactic error recovery. + +We still have the possibility to return an invalid token number, which +does the trick. But then the error message from the parser is poor +(something like "unexpected $undefined"). Since the scanner probably +already reported the error, we should directly enter error-recovery, +without reporting the error message (i.e., YYERROR's semantics). + +Back to lalr1.cc (whose name is now quite unfortunate, since it also +covers lr and ielr), if we support exceptions from yylex, should we +propose a lexical_error in addition to syntax_error? Should they have +a common root, say parse_error? Should syntax_error be renamed +syntactic_error for consistency with lexical_error? + +** 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 |