X-Git-Url: https://git.saurik.com/bison.git/blobdiff_plain/2ab9a04ffcf892a695e099c3a01d369d5101b5ea..f377f69fec28013c79db4efe12bbb9d48987fb2c:/TODO?ds=inline
diff --git a/TODO b/TODO
index 52b2457e..e33f3aee 100644
--- a/TODO
+++ b/TODO
@@ -1,9 +1,74 @@
-*- 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.
+* Documentation
+Before releasing, make sure the documentation refers to the current
+`output' format.
+
+
* Error messages
Some are really funky. For instance
@@ -11,30 +76,6 @@ Some are really funky. For instance
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
@@ -72,7 +113,7 @@ a sample text exhibiting the (LALR) ambiguity. See the paper from
DeRemer and Penello: they already provide the algorithm.
-* Extentions
+* Extensions
** yyerror, yysymprint interface
It should be improved, in particular when using Bison features such as
@@ -121,19 +162,31 @@ this issue. Does anybody have it?
* Documentation
-** 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?
+* Java, Fortran, etc.
+
+
+** Java
+
+There are a couple of proposed outputs:
+
+- BYACC/J
+ which is based on Byacc.
+
+
+- Bison Java
+ which is based on Bison.
+
+
+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:
@@ -159,7 +212,7 @@ Show reductions. []
** %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 []
@@ -176,7 +229,7 @@ Find the best graph parameters. []
* doc/bison.texinfo
** Update
informations about ERROR_VERBOSE. []
-** Add explainations about
+** Add explanations about
skeleton muscles. []
%skeleton. []
@@ -197,7 +250,7 @@ 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
+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.