Update.

diff --git a/README-cvs b/README-cvs
index dd0b18d74c2123ee1418ad34e41ada37b4384bca..2495479227b761d1f053e7336fb4866023433350 100644 (file)
--- a/README-cvs
+++ b/README-cvs
@@ -1,13 +1,22 @@
+-*- outline -*-
+

 These notes intend to help people working on the CVS versions of
 These notes intend to help people working on the CVS versions of

-Bison.  Only the sources are installed in the CVS repository (to ease
-the maintenance, merges etc.), therefore you will have to the
-maintainer tools we depend upon:
+Bison.
+
+* Requirements
+
+Only the sources are installed in the CVS repository (to ease the
+maintenance, merges etc.), therefore you will have to the maintainer
+tools we depend upon:

 
 - Automake 1.6 or 1.6.1
 
 - Automake 1.6 or 1.6.1

+

 - Autoconf 2.53a or better
   ftp://alpha.gnu.org/gnu/autoconf/autoconf-2.53a.tar.gz   (992 kB)
   ftp://alpha.gnu.org/gnu/autoconf/autoconf-2.53a.tar.bz2  (756 kB)
 - Autoconf 2.53a or better
   ftp://alpha.gnu.org/gnu/autoconf/autoconf-2.53a.tar.gz   (992 kB)
   ftp://alpha.gnu.org/gnu/autoconf/autoconf-2.53a.tar.bz2  (756 kB)

-- Gettext 0.11.3
+
+- Gettext 0.11.3 pre 2 or better
+  http://www.lrde.epita.fr/~akim/download/gettext-0.11.3-pre2.tar.gz

 
 Only building the initial full source tree will be a bit painful,
 later, a plain `cvs update -P & make' should be sufficient.
 
 Only building the initial full source tree will be a bit painful,
 later, a plain `cvs update -P & make' should be sufficient.


@@ -44,13 +53,18 @@ needed tools so that the bootstrapping always perform successfully.
 
 If you experiment problems, I suggest the following:
 
 
 If you experiment problems, I suggest the following:
 

-1. do a regular CVS checkout
-2. fetch http://www.lrde.epita.fr/~akim/download/bison-1.49b.tar.gz
-3. extract it
-4. override the content of your checkout with the content of this
+1. Do a regular CVS checkout
+
+2. Fetch a recent tarball.
+   http://www.lrde.epita.fr/~akim/download/bison-1.49b.tar.gz
+
+3. Extract it
+
+4. Override the content of your checkout with the content of this

    tarball, i.e.:
    cp -r bison-1.49b/* bison-cvs
    tarball, i.e.:
    cp -r bison-1.49b/* bison-cvs

-5. proceed on ./configure && make etc.
+
+5. Proceed on ./configure && make etc.

 
 -----
 
 
 -----
 

diff --git a/TODO b/TODO
index 9750583007fa39da6b42614a8d6f68a26523cf5d..52b2457ea866c39134682681dcf058e285639aac 100644 (file)
--- a/TODO
+++ b/TODO
@@ -3,52 +3,83 @@
 * 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.
+* Error messages
+Some are really funky.  For instance
+
+       type clash (`%s' `%s') on default action
+
+is really weird.  Revisit them all.
+
+* 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 '('
+
+
+* 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?
 
 
 * 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
-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, ?).  Should we also rename `$'?
-BYacc uses `$end'.  `$eof' is attracting, but after all we may be
-parsing a string, a stream etc.
+* Report

 
 

-* Error messages
-Some are really funky.  For instance
-
-       type clash (`%s' `%s') on default action
+**  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.

 
 

-is really weird.  Revisit them all.
+** Disabled Reductions
+See `tests/conflicts.at (Defaulted Conflicted Reduction)', and decide
+what we want to do.

 
 

-* Report documentation
+** 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?
 
 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?
+** --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.
+

 
 

-* Several %unions
+* 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


@@ -69,24 +100,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
 


@@ -104,37 +117,38 @@ 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 '('
+** Vocabulary
+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, ?).  Should we also rename `$'?
+BYacc uses `$end'.  `$eof' is attracting, but after all we may be
+parsing a string, a stream etc.
+
+** 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.       []


@@ -178,18 +192,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


@@ -198,6 +241,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


@@ -214,6 +258,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


@@ -224,6 +269,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