summaryrefslogtreecommitdiff
path: root/TODO
diff options
context:
space:
mode:
authorAkim Demaille <demaille@gostai.com>2009-09-17 09:41:21 +0200
committerAkim Demaille <demaille@gostai.com>2009-09-17 09:43:23 +0200
commit5ad90d528dc5feedb0c1d8afe82719440ec17217 (patch)
tree38e6854d19c41383464980cd518e576ff53d8931 /TODO
parenta6ca4ce2292277b4af21b5069bded9c73341d23a (diff)
downloadbison-5ad90d528dc5feedb0c1d8afe82719440ec17217.tar.gz
todo: short term
* TODO (syntax_error, variable names): New.
Diffstat (limited to 'TODO')
-rw-r--r--TODO22
1 files changed, 22 insertions, 0 deletions
diff --git a/TODO b/TODO
index 216c97f4..c3aac317 100644
--- a/TODO
+++ b/TODO
@@ -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