]> git.saurik.com Git - bison.git/blobdiff - TODO
(AC_INIT): Version 1.50.
[bison.git] / TODO
diff --git a/TODO b/TODO
index 56038fc633fe45fe039748ce7fffda704db774a4..e33f3aeed0f77dda5b717af0a03fe14f2dcb3a95 100644 (file)
--- a/TODO
+++ b/TODO
@@ -1,5 +1,65 @@
 -*- 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.
 
@@ -16,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
@@ -77,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
@@ -132,6 +168,25 @@ 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:
@@ -157,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       []
@@ -174,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.             []
 
@@ -195,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.