* src/state.h, src/state.c (transitions_t): Holds state_t*'s, not

[bison.git] / TODO

diff --git a/TODO b/TODO
index 840580d1188cd7e9052c39d6683fe3c9d9d99f66..56038fc633fe45fe039748ce7fffda704db774a4 100644 (file)
--- a/TODO
+++ b/TODO
@@ -3,20 +3,11 @@
 * URGENT: Documenting C++ output
 Write a first documentation for C++ output.
 
 * URGENT: Documenting C++ output
 Write a first documentation for C++ output.
 

-* 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
-union, doesn't she?

 
 

-* yyerror, yyprint interface
-It should be improved, in particular when using Bison features such as
-locations, and YYPARSE_PARAMS.  For the time being, it is recommended
-to #define yyerror and yyprint to steal internal variables...
+* Documentation
+Before releasing, make sure the documentation refers to the current
+`output' format.

 
 

-* documentation
-Explain $axiom (and maybe change its name: BTYacc names it `goal',
-byacc `$accept' probably based on AT&T Yacc, Meta `Start'...).
-Complete the glossary (item, axiom, ?).

 
 * Error messages
 Some are really funky.  For instance
 
 * Error messages
 Some are really funky.  For instance


@@ -25,18 +16,75 @@ Some are really funky.  For instance
 
 is really weird.  Revisit them all.
 
 
 is really weird.  Revisit them all.
 

-* 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?
+* Stupid error messages
+An example shows it easily:
+
+src/bison/tests % ./testsuite -k calc,location,error-verbose -l
+GNU Bison 1.49a test suite test groups:
+
+ NUM: FILENAME:LINE      TEST-GROUP-NAME
+      KEYWORDS
+
+  51: calc.at:440        Calculator --locations --yyerror-verbose
+  52: calc.at:442        Calculator --defines --locations --name-prefix=calc --verbose --yacc --yyerror-verbose
+  54: calc.at:445        Calculator --debug --defines --locations --name-prefix=calc --verbose --yacc --yyerror-verbose
+src/bison/tests % ./testsuite 51 -d
+## --------------------------- ##
+## GNU Bison 1.49a test suite. ##
+## --------------------------- ##
+ 51: calc.at:440       ok
+## ---------------------------- ##
+## All 1 tests were successful. ##
+## ---------------------------- ##
+src/bison/tests % cd ./testsuite.dir/51
+tests/testsuite.dir/51 % echo "()" | ./calc
+1.2-1.3: parse error, unexpected ')', expecting error or "number" or '-' or '('

 
 

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

 
 

-* Several %unions
+* read_pipe.c
+This is not portable to DOS for instance.  Implement a more portable
+scheme.  Sources of inspiration include GNU diff, and Free Recode.
+
+
+* 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
+union, doesn't she?
+
+
+* Report
+
+**  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.
+
+** 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.
+
+
+* Extentions
+
+** yyerror, yysymprint interface
+It should be improved, in particular when using Bison features such as
+locations, and YYPARSE_PARAMS.  For the time being, it is recommended
+to #define yyerror and yyprint to steal internal variables...
+
+** Several %unions

 I think this is a pleasant (but useless currently) feature, but in the
 future, I want a means to %include other bits of grammars, and _then_
 it will be important for the various bits to define their needs in
 I think this is a pleasant (but useless currently) feature, but in the
 future, I want a means to %include other bits of grammars, and _then_
 it will be important for the various bits to define their needs in


@@ -57,24 +105,6 @@ When implementing multiple-%union support, bare the following in mind:
          char *sval;
        }
 
          char *sval;
        }
 

-* --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.
-
-* 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.
-

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


@@ -92,37 +122,31 @@ 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?
 
 `Parsing Techniques: a Practical Guide', it includes information about
 this issue.  Does anybody have it?
 

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

 
 

-src/bison/tests % ./testsuite -k calc,location,error-verbose -l
-GNU Bison 1.49a test suite test groups:

 
 

- NUM: FILENAME:LINE      TEST-GROUP-NAME
-      KEYWORDS
+* Documentation

 
 

-  51: calc.at:440        Calculator --locations --yyerror-verbose
-  52: calc.at:442        Calculator --defines --locations --name-prefix=calc --verbose --yacc --yyerror-verbose
-  54: calc.at:445        Calculator --debug --defines --locations --name-prefix=calc --verbose --yacc --yyerror-verbose
-src/bison/tests % ./testsuite 51 -d
-## --------------------------- ##
-## GNU Bison 1.49a test suite. ##
-## --------------------------- ##
- 51: calc.at:440       ok
-## ---------------------------- ##
-## All 1 tests were successful. ##
-## ---------------------------- ##
-src/bison/tests % cd ./testsuite.dir/51
-tests/testsuite.dir/51 % echo "()" | ./calc
-1.2-1.3: parse error, unexpected ')', expecting error or "number" or '-' or '('
+** 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.

 
 

-* read_pipe.c
-This is not portable to DOS for instance.  Implement a more portable
-scheme.  Sources of inspiration include GNU diff, and Free Recode.

 
 

-* Memory leaks in the generator
-A round of memory leak clean ups would be most welcome.  Dmalloc,
-Checker GCC, Electric Fence, or Valgrind: you chose your tool.

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


@@ -166,18 +190,47 @@ 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.
 

-* RR conflicts
-See if we can use precedence between rules to solve RR conflicts.  See
-what POSIX says.
+** Keeping the conflicted actions
+First, analyze the differences between byacc and btyacc (I'm referring
+to the executables).  Find where the conflicts are preserved.
+
+** Compare with the GLR tables
+See how isomorphic the way BTYacc and the way the GLR adjustements in
+Bison are compatible.  *As much as possible* one should try to use the
+same implementation in the Bison executables.  I insist: it should be
+very feasible to use the very same conflict tables.
+
+** Adjust the skeletons
+Import the skeletons for C and C++.
+
+** Improve the skeletons
+Have them support yysymprint, yydestruct and so forth.
+

 
 * Precedence
 
 * Precedence

+
+** Partial order

 It is unfortunate that there is a total order for precedence.  It
 makes it impossible to have modular precedence information.  We should
 It is unfortunate that there is a total order for precedence.  It
 makes it impossible to have modular precedence information.  We should

-move to partial orders.
+move to partial orders (sounds like series/parallel orders to me).

 
 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.
 

+** 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
+See if we can use precedence between rules to solve RR conflicts.  See
+what POSIX says.
+
+

 * $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


@@ -186,6 +239,7 @@ addition to the $undefined value.
 
 Suggest: Change the name $undefined to undefined; looks better in outputs.
 
 
 Suggest: Change the name $undefined to undefined; looks better in outputs.
 

+

 * Default Action
 From Hans:
 - For use with my C++ parser, I transported the "switch (yyn)" statement
 * Default Action
 From Hans:
 - For use with my C++ parser, I transported the "switch (yyn)" statement


@@ -202,6 +256,7 @@ a Bison option where every typed default rule is explicitly written out
 
 Note: Robert Anisko handles this.  He knows how to do it.
 
 
 Note: Robert Anisko handles this.  He knows how to do it.
 

+

 * Warnings
 It would be nice to have warning support.  See how Autoconf handles
 them, it is fairly well described there.  It would be very nice to
 * Warnings
 It would be nice to have warning support.  See how Autoconf handles
 them, it is fairly well described there.  It would be very nice to


@@ -212,6 +267,7 @@ Don't work on this without first announcing you do, as I already have
 thought about it, and know many of the components that can be used to
 implement it.
 
 thought about it, and know many of the components that can be used to
 implement it.
 

+

 * Pre and post actions.
 From: Florian Krohm <florian@edamail.fishkill.ibm.com>
 Subject: YYACT_EPILOGUE
 * Pre and post actions.
 From: Florian Krohm <florian@edamail.fishkill.ibm.com>
 Subject: YYACT_EPILOGUE


@@ -248,19 +304,19 @@ 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.