X-Git-Url: https://git.saurik.com/bison.git/blobdiff_plain/88bce5a2ef15e5b508749e75ddad709aca85b019..c0ad8bf3c2fb46f001bb24ac98a72b8bfb3a77ce:/TODO diff --git a/TODO b/TODO index 56038fc6..ad99639d 100644 --- 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,14 @@ Are there any Texinfo standards for bibliography? +* Java, Fortran, etc. + + Add support for languages other than C and C++. Here is a proposed + patch for Java: + + + + * Coding system independence Paul notes: @@ -157,7 +201,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 +218,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 +239,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.