* src/output.c (prepare_actions): Free `tally' and `width'.

[bison.git] / TODO

diff --git a/TODO b/TODO
index 14bd676f20c3ccac8de849a7460a86adf61a277e..9750583007fa39da6b42614a8d6f68a26523cf5d 100644 (file)
--- a/TODO
+++ b/TODO
@@ -3,6 +3,16 @@
 * URGENT: Documenting C++ output
 Write a first documentation for C++ output.
 
 * URGENT: Documenting C++ output
 Write a first documentation for C++ output.
 

+* Report and GLR
+How would Paul like to display the conflicted actions?  In particular,
+what when two reductions are possible on a given lookahead, but one is
+part of $default.  Should we make the two reductions explicit, or just
+keep $default?  See the following point.
+
+* Report and Disabled Reductions
+See `tests/conflicts.at (Defaulted Conflicted Reduction)', and decide
+what we want to do.
+

 * value_components_used
 Was defined but not used: where was it coming from?  It can't be to
 check if %union is used, since the user is free to $<foo>n on her
 * value_components_used
 Was defined but not used: where was it coming from?  It can't be to
 check if %union is used, since the user is free to $<foo>n on her


@@ -15,17 +25,26 @@ to #define yyerror and yyprint to steal internal variables...
 
 * documentation
 Explain $axiom (and maybe change its name: BTYacc names it `goal',
 
 * documentation
 Explain $axiom (and maybe change its name: BTYacc names it `goal',

-byacc `$accept', probably based on AT&T Yacc).  Complete the glossary
-(item, axiom, ?).
+byacc `$accept' probably based on AT&T Yacc, Meta `Start'...).
+Complete the glossary (item, axiom, ?).  Should we also rename `$'?
+BYacc uses `$end'.  `$eof' is attracting, but after all we may be
+parsing a string, a stream etc.

 
 

-* report documentation
-Extend with error.  The hard part will probably be finding the right
-rule so that a single state does not exhibit to 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?
+* Error messages
+Some are really funky.  For instance

 
 

-* documentation
+       type clash (`%s' `%s') on default action
+
+is really weird.  Revisit them all.
+
+* Report 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?
+
+* Documentation

 Some history of Bison and some bibliography would be most welcome.
 Are there any Texinfo standards for bibliography?
 
 Some history of Bison and some bibliography would be most welcome.
 Are there any Texinfo standards for bibliography?
 


@@ -52,7 +71,8 @@ When implementing multiple-%union support, bare the following in mind:
 
 * --report=conflict-path
 Provide better assistance for understanding the conflicts by providing
 
 * --report=conflict-path
 Provide better assistance for understanding the conflicts by providing

-a sample text exhibiting the (LALR) ambiguity.
+a sample text exhibiting the (LALR) ambiguity.  See the paper from
+DeRemer and Penello: they already provide the algorithm.

 
 * Coding system independence
 Paul notes:
 
 * Coding system independence
 Paul notes:


@@ -67,77 +87,6 @@ Paul notes:
        PDP-10 ports :-) but they should probably be documented
        somewhere.
 
        PDP-10 ports :-) but they should probably be documented
        somewhere.
 

-* Output directory
-Akim:
-
-| I consider this to be a bug in bison:
-|
-| /tmp % mkdir src
-| /tmp % cp ~/src/bison/tests/calc.y src
-| /tmp % mkdir build && cd build
-| /tmp/build % bison ../src/calc.y
-| /tmp/build % cd ..
-| /tmp % ls -l build src
-| build:
-| total 0
-|
-| src:
-| total 32
-| -rw-r--r--    1 akim     lrde        27553 oct  2 16:31 calc.tab.c
-| -rw-r--r--    1 akim     lrde         3335 oct  2 16:31 calc.y
-|
-|
-| Would it be safe to change this behavior to something more reasonable?
-| Do you think some people depend upon this?
-
-Jim:
-
-Is it that behavior documented?
-If so, then it's probably not reasonable to change it.
-I've Cc'd the automake list, because some of automake's
-rules use bison through $(YACC) -- though I'll bet they
-all use it in yacc-compatible mode.
-
-Pavel:
-
-Hello, Jim and others!
-
-> Is it that behavior documented?
-> If so, then it's probably not reasonable to change it.
-> I've Cc'd the automake list, because some of automake's
-> rules use bison through $(YACC) -- though I'll bet they
-> all use it in yacc-compatible mode.
-
-Yes, Automake currently used bison in Automake-compatible mode, but it
-would be fair for Automake to switch to the native mode as long as the
-processed files are distributed and "missing" emulates bison.
-
-In any case, the makefiles should specify the output file explicitly
-instead of relying on weird defaults.
-
-> | src:
-> | total 32
-> | -rw-r--r--    1 akim     lrde        27553 oct  2 16:31 calc.tab.c
-> | -rw-r--r--    1 akim     lrde         3335 oct  2 16:31 calc.y
-
-This is not _that_ ugly as it seems - with Automake you want to put
-sources where they belong - to the source directory.
-
-> | This is not _that_ ugly as it seems - with Automake you want to put
-> | sources where they belong - to the source directory.
->
-> The difference source/build you are referring to is based on Automake
-> concepts.  They have no sense at all for tools such as bison or gcc
-> etc.  They have input and output.  I do not want them to try to grasp
-> source/build.  I want them to behave uniformly: output *here*.
-
-I realize that.
-
-It's unfortunate that the native mode of Bison behaves in a less uniform
-way than the yacc mode. I agree with your point. Bison maintainters may
-want to fix it along with the documentation.
-
-

 * Unit rules
 Maybe we could expand unit rules, i.e., transform
 
 * Unit rules
 Maybe we could expand unit rules, i.e., transform
 


@@ -150,7 +99,10 @@ into
        exp: exp '+' exp | exp '&' exp;
 
 when there are no actions.  This can significantly speed up some
        exp: exp '+' exp | exp '&' exp;
 
 when there are no actions.  This can significantly speed up some

-grammars.
+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?

 
 * Stupid error messages
 An example shows it easily:
 
 * Stupid error messages
 An example shows it easily:


@@ -184,12 +136,6 @@ scheme.  Sources of inspiration include GNU diff, and Free Recode.
 A round of memory leak clean ups would be most welcome.  Dmalloc,
 Checker GCC, Electric Fence, or Valgrind: you chose your tool.
 
 A round of memory leak clean ups would be most welcome.  Dmalloc,
 Checker GCC, Electric Fence, or Valgrind: you chose your tool.
 

-* Memory leaks in the parser
-The same applies to the generated parsers.  In particular, this is
-critical for user data: when aborting a parsing, when handling the
-error token etc., we often throw away yylval without giving a chance
-of cleaning it up to the user.
-

 * --graph
 Show reductions.       []
 
 * --graph
 Show reductions.       []
 


@@ -224,59 +170,6 @@ skeleton muscles.  []
 ** tests/pure-parser.at        []
 New tests.
 
 ** tests/pure-parser.at        []
 New tests.
 

-* Debugging parsers
-
-From Greg McGary:
-
-akim demaille <akim.demaille@epita.fr> writes:
-
-> With great pleasure!  Nonetheless, things which are debatable
-> (or not, but just `big') should be discuss in `public': something
-> like help- or bug-bison@gnu.org is just fine.  Jesse and I are there,
-> but there is also Jim and some other people.
-
-I have no idea whether it qualifies as big or controversial, so I'll
-just summarize for you.  I proposed this change years ago and was
-surprised that it was met with utter indifference!
-
-This debug feature is for the programs/grammars one develops with
-bison, not for debugging bison itself.  I find that the YYDEBUG
-output comes in a very inconvenient format for my purposes.
-When debugging gcc, for instance, what I want is to see a trace of
-the sequence of reductions and the line#s for the semantic actions
-so I can follow what's happening.  Single-step in gdb doesn't cut it
-because to move from one semantic action to the next takes you through
-lots of internal machinery of the parser, which is uninteresting.
-
-The change I made was to the format of the debug output, so that it
-comes out in the format of C error messages, digestible by emacs
-compile mode, like so:
-
-grammar.y:1234: foo: bar(0x123456) baz(0x345678)
-
-where "foo: bar baz" is the reduction rule, whose semantic action
-appears on line 1234 of the bison grammar file grammar.y.  The hex
-numbers on the rhs tokens are the parse-stack values associated with
-those tokens.  Of course, yytype might be something totally
-incompatible with that representation, but for the most part, yytype
-values are single words (scalars or pointers).  In the case of gcc,
-they're most often pointers to tree nodes.  Come to think of it, the
-right thing to do is to make the printing of stack values be
-user-definable.  It would also be useful to include the filename &
-line# of the file being parsed, but the main filename & line# should
-continue to be that of grammar.y
-
-Anyway, this feature has saved my life on numerous occasions.  The way
-I customarily use it is to first run bison with the traces on, isolate
-the sequence of reductions that interests me, put those traces in a
-buffer and force it into compile-mode, then visit each of those lines
-in the grammar and set breakpoints with C-x SPACE.  Then, I can run
-again under the control of gdb and stop at each semantic action.
-With the hex addresses of tree nodes, I can inspect the values
-associated with any rhs token.
-
-You like?
-

 * input synclines
 Some users create their foo.y files, and equip them with #line.  Bison
 should recognize these, and preserve them.
 * input synclines
 Some users create their foo.y files, and equip them with #line.  Bison
 should recognize these, and preserve them.


@@ -285,9 +178,6 @@ should recognize these, and preserve them.
 See if we can integrate backtracking in Bison.  Contact the BTYacc
 maintainers.
 
 See if we can integrate backtracking in Bison.  Contact the BTYacc
 maintainers.
 

-* Automaton report
-Display more clearly the lookaheads for each item.
-

 * RR conflicts
 See if we can use precedence between rules to solve RR conflicts.  See
 what POSIX says.
 * RR conflicts
 See if we can use precedence between rules to solve RR conflicts.  See
 what POSIX says.


@@ -300,11 +190,6 @@ move to partial orders.
 This will be possible with a Bison parser for the grammar, as it will
 make it much easier to extend the grammar.
 
 This will be possible with a Bison parser for the grammar, as it will
 make it much easier to extend the grammar.
 

-* Parsing grammars
-Rewrite the reader in Flex/Bison.  There will be delicate parts, in
-particular, expect the scanner to be hard to write.  Many interesting
-features cannot be implemented without such a new reader.
-

 * $undefined
 From Hans:
 - If the Bison generated parser experiences an undefined number in the
 * $undefined
 From Hans:
 - If the Bison generated parser experiences an undefined number in the


@@ -367,23 +252,27 @@ at the proper place to bison.simple. Ditto for YYACT_PROLOGUE.
 I was wondering what you think about adding YYACT_PROLOGUE/EPILOGUE
 to bison. If you're interested, I'll work on a patch.
 
 I was wondering what you think about adding YYACT_PROLOGUE/EPILOGUE
 to bison. If you're interested, I'll work on a patch.
 

+* Move to Graphviz
+Well, VCG seems really dead.  Move to Graphviz instead.  Also, equip
+the parser with a means to create the (visual) parse tree.
+

 -----
 
 Copyright (C) 2001, 2002 Free Software Foundation, Inc.
 
 -----
 
 Copyright (C) 2001, 2002 Free Software Foundation, Inc.
 

-This file is part of GNU Autoconf.
+This file is part of GNU Bison.

 
 

-GNU Autoconf is free software; you can redistribute it and/or modify
+GNU Bison is free software; you can redistribute it and/or modify

 it under the terms of the GNU General Public License as published by
 the Free Software Foundation; either version 2, or (at your option)
 any later version.
 
 it under the terms of the GNU General Public License as published by
 the Free Software Foundation; either version 2, or (at your option)
 any later version.
 

-GNU Autoconf is distributed in the hope that it will be useful,
+GNU Bison is distributed in the hope that it will be useful,

 but WITHOUT ANY WARRANTY; without even the implied warranty of
 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 GNU General Public License for more details.
 
 You should have received a copy of the GNU General Public License
 but WITHOUT ANY WARRANTY; without even the implied warranty of
 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 GNU General Public License for more details.
 
 You should have received a copy of the GNU General Public License

-along with autoconf; see the file COPYING.  If not, write to
+along with Bison; see the file COPYING.  If not, write to

 the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
 Boston, MA 02111-1307, USA.
 the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
 Boston, MA 02111-1307, USA.