+** 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 François: should we keep the directory part in the CPP guard?
+
+
+* Yacc.c: CPP Macros
+
+Do some people use YYPURE, YYLSP_NEEDED like we do in the test suite?
+They should not: it is not documented. But if they need to, let's
+find something clean (not like YYLSP_NEEDED...).
+
+* 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
+part of $default. Should we make the two reductions explicit, or just
+keep $default? See the following point.
+
+** Disabled Reductions
+See `tests/conflicts.at (Defaulted Conflicted Reduction)', and decide
+what we want to do.
+
+** Documentation
+Extend with error productions. The hard part will probably be finding
+the right rule so that a single state does not exhibit too many yet
+undocumented ``features''. Maybe an empty action ought to be
+presented too. Shall we try to make a single grammar with all these
+features, or should we have several very small grammars?
+
+** --report=conflict-path
+Provide better assistance for understanding the conflicts by providing
+a sample text exhibiting the (LALR) ambiguity. See the paper from
+DeRemer and Penello: they already provide the algorithm.
+
+** Statically check for potential ambiguities in GLR grammars. See
+<http://www.i3s.unice.fr/~schmitz/papers.html#expamb> for an approach.
+
+
+* Extensions
+
+** $-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; }
+
+we should be able to have:
+
+ foo($foo) bar($bar) baz($bar): qux($qux) { $baz = $foo + $bar + $qux; }
+
+Or something like this.
+
+** %if and the like
+It should be possible to have %if/%else/%endif. The implementation is
+not clear: should it be lexical or syntactic. Vadim Maslow thinks it
+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.
+
+** XML Output
+There are couple of available extensions of Bison targeting some XML
+output. Some day we should consider including them. One issue is
+that they seem to be quite orthogonal to the parsing technique, and
+seem to depend mostly on the possibility to have some code triggered
+for each reduction. As a matter of fact, such hooks could also be
+used to generate the yydebug traces. Some generic scheme probably
+exists in there.
+
+XML output for GNU Bison and gcc
+ http://www.cs.may.ie/~jpower/Research/bisonXML/
+
+XML output for GNU Bison
+ http://yaxx.sourceforge.net/
+
+* Unit rules
+Maybe we could expand unit rules, i.e., transform
+
+ exp: arith | bool;
+ arith: exp '+' exp;
+ bool: exp '&' exp;
+
+into
+
+ 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
+parsing: Theory and Practice' is impossible to find, but according to
+`Parsing Techniques: a Practical Guide', it includes information about
+this issue. Does anybody have it?
+
+
+
+* Documentation
+
+** History/Bibliography
+Some history of Bison and some bibliography would be most welcome.
+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.
+
+ 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.
projects / bison.git / blobdiff