* doc/bison.texinfo (Stack Overflow): xref to Recursion.

[bison.git] / TODO

diff --git a/TODO b/TODO
index 9750583007fa39da6b42614a8d6f68a26523cf5d..e33f3aeed0f77dda5b717af0a03fe14f2dcb3a95 100644 (file)
--- a/TODO
+++ b/TODO
@@ -1,54 +1,126 @@
 -*- outline -*-
 
 -*- outline -*-
 

+* Header guards
+
+En rentrant chez moi, je relance un `make' sur un projet que j'ai avancé
+ailleurs durant la semaine.  Le système que j'utilise ici est un peu plus
+à jour que l'autre, et le Bison est probablement plus récent itou.  Ici,
+c'est la version 1.33.  J'obtiens, en montrant un peu plus que nécessaire:
+
+---------------------------------------------------------------------->
+cd ~/fpub/pyrexpp/Pyrexpp/
+LANGUAGE= /usr/bin/make MAKEFLAGS='-k -j2'
+/usr/bin/make -C .. install
+make[1]: Entre dans le répertoire `/bpi/titan/home/pinard/fpub/pyrexpp'
+install -g bpi -m 2775 -d Prépare-titan
+chmod g+sw Prépare-titan
+touch Prépare-titan/.estampille
+/usr/bin/gcc  -fPIC -I/usr/include/python2.2 -IPrépare-titan -g -c -o Prépare-titan/ctools.o ctools.c
+bison -d -o Prépare-titan/c-parser.c c-parser.y
+/usr/bin/gcc  -fPIC -I/usr/include/python2.2 -IPrépare-titan -g -c -o Prépare-titan/c-parser.o Prépare-titan/c-parser.c
+flex -t c-scanner.l | grep -v '^#line' > Prépare-titan/c-scanner.c
+/usr/bin/gcc  -fPIC -I/usr/include/python2.2 -IPrépare-titan -g -c -o Prépare-titan/c-scanner.o Prépare-titan/c-scanner.c
+In file included from Prépare-titan/c-scanner.c:547:
+Prépare-titan/c-parser.h:1: warning: garbage at end of `#ifndef' argument
+Prépare-titan/c-parser.h:2: warning: missing white space after `#define BISON_PR'
+/usr/bin/gcc -o Prépare-titan/ctools.so Prépare-titan/ctools.o Prépare-titan/c-scanner.o -shared -lm
+python setup.py --quiet build
+install -g bpi -m 664 Prépare-titan/ctools.so /bpi/titan/local/lib/python2.2/site-packages/Pyrexpp
+python setup.py --quiet install
+make[1]: Quitte le répertoire `/bpi/titan/home/pinard/fpub/pyrexpp'
+[...]
+----------------------------------------------------------------------<
+
+Diagnostics que je n'avais sûrement pas, plus tôt en journée, sur l'autre
+système.  En allant voir, je trouve:
+
+---------------------------------------------------------------------->
+#ifndef BISON_PRÉPARE_TITAN_C_PARSER_H
+# define BISON_PRÉPARE_TITAN_C_PARSER_H
+
+# ifndef YYSTYPE
+#  define YYSTYPE int
+# endif
+# define       IDENTIFIER      257
+[...]
+
+extern YYSTYPE yylval;
+
+#endif /* not BISON_PRÉPARE_TITAN_C_PARSER_H */
+----------------------------------------------------------------------<
+
+Le pré-processeur de C n'est pas à l'aise avec les caractères accentués
+dans les identificateurs.
+
+Bon, de mon expérience, il n'a jamais été nécessaire de protéger un fichier
+`.h' de Bison ou Yacc contre de multiples inclusions, mais si ça été
+fait, je présume qu'il y avait un problème réel et convaincant à régler,
+et qu'il ne s'agit pas d'une simple fantaisie: je ne mettrai donc pas
+ça en doute.  Mais le choix du nom de l'identificateur laisse à désirer,
+tu en conviendras :-).  Et faut-il vraiment y inclure le répertoire?
+
+

 * 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.
+* Documentation
+Before releasing, make sure the documentation refers to the current
+`output' format.
+
+
+* Error messages
+Some are really funky.  For instance
+
+       type clash (`%s' `%s') on default action
+
+is really weird.  Revisit them all.
+
+
+* 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.
-
-* Error messages
-Some are really funky.  For instance
+* Report

 
 

-       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
+
+* Extensions
+
+** 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 +141,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 +158,50 @@ 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
-
-  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.

 
 

-* 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.
+* Documentation
+
+** History/Bibliography
+Some history of Bison and some bibliography would be most welcome.
+Are there any Texinfo standards for bibliography?
+
+
+
+* Java, Fortran, etc.
+
+
+** Java
+
+There are a couple of proposed outputs:
+
+- BYACC/J
+  which is based on Byacc.
+  <http://troi.lincom-asg.com/~rjamison/byacc/>
+
+- Bison Java
+  which is based on Bison.
+  <http://www.goice.co.jp/member/mo/hack-progs/bison-java.html>
+
+Sébastien Serrurier (serrur_s@epita.fr) is working on this: he is
+expected to contact the authors, design the output, and implement it
+into Bison.
+
+
+* 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.
+
+

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


@@ -145,7 +212,7 @@ Show reductions.    []
 ** %pure-parser                []
 ** %token-table                []
 ** Options which could use parse_dquoted_param ().
 ** %pure-parser                []
 ** %token-table                []
 ** Options which could use parse_dquoted_param ().

-Maybe transfered in lex.c.
+Maybe transferred in lex.c.

 *** %skeleton          [ok]
 *** %output            []
 *** %file-prefix       []
 *** %skeleton          [ok]
 *** %output            []
 *** %file-prefix       []


@@ -162,7 +229,7 @@ Find the best graph parameters.     []
 * doc/bison.texinfo
 ** Update
 informations about ERROR_VERBOSE.      []
 * doc/bison.texinfo
 ** Update
 informations about ERROR_VERBOSE.      []

-** Add explainations about
+** Add explanations about

 skeleton muscles.      []
 %skeleton.             []
 
 skeleton muscles.      []
 %skeleton.             []
 


@@ -178,18 +245,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 adjustments 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 +294,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 +311,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 +322,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