4 Don't do this (counterexample.c):
6 // This is the fastest way to get the tail node from the gl_list API.
8 list_get_end (gl_list_t list)
10 gl_list_node_t sentinel = gl_list_add_last (list, NULL);
11 gl_list_node_t res = gl_list_previous_node (list, sentinel);
12 gl_list_remove_node (list, sentinel);
16 *** Ambiguous rewriting
17 If the user is stupid enough to have equal rules, then the derivations are
20 Reduce/reduce conflict on tokens $end, "+", "⊕":
24 First derivation exp ::=[ exp "+" exp • ]
26 Second derivation exp ::=[ exp "+" exp • ]
28 Do we care about this? In color, we use twice the same color here, but we
29 could try to use the same color for the same rule.
32 Show the counterexamples. This is going to be really hard and/or painful.
33 Unless we play it dumb (little structure).
36 - How about not evaluating incomplete lines when the text is not finished
41 - Should i18n be part of the Lexer? Currently it's a static method of
44 - is there a migration path that would allow to use TokenKinds in
47 - define the tokens as an enum too.
49 - promote YYEOF rather than EOF.
52 https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=blob;f=gettext-runtime/intl/plural.y;h=a712255af4f2f739c93336d4ff6556d932a426a5;hb=HEAD
54 should be updated to not use YYERRCODE. Returning an undef token is good
59 Stop hard-coding "Calc". Adjust local.at (look for FIXME).
61 ** A dev warning for b4_
62 Maybe we should check for m4_ and b4_ leaking out of the m4 processing, as
63 Autoconf does. It would have caught over-quotation issues.
66 I feel it's ugly to use the GNU style to declare functions in the doc. It
67 generates tons of white space in the page, and may contribute to bad page
74 The YYUNDEFTOK could be assigned a semantic value so that yyerror could be
75 used to report invalid lexemes.
78 Consider deprecating impure push parsers. They add a lot of complexity, for
79 a bad feature. On the other hand, that would make it much harder to sit
80 push parsers on top of pull parser. Which is currently not relevant, since
81 push parsers are measurably slower.
83 ** %define parse.error formatted
84 How about pushing Bistromathic's yyreport_syntax_error as another standard
85 way to generate the error message, and leave to the user the task of
86 providing the message formats? Currently in bistro, it reads:
89 error_format_string (int argc)
93 default: /* Avoid compiler warnings. */
94 case 0: return _("%@: syntax error");
95 case 1: return _("%@: syntax error: unexpected %u");
96 // TRANSLATORS: '%@' is a location in a file, '%u' is an
97 // "unexpected token", and '%0e', '%1e'... are expected tokens
100 // For instance on the expression "1 + * 2", you'd get
102 // 1.5: syntax error: expected - or ( or number or function or variable before *
103 case 2: return _("%@: syntax error: expected %0e before %u");
104 case 3: return _("%@: syntax error: expected %0e or %1e before %u");
105 case 4: return _("%@: syntax error: expected %0e or %1e or %2e before %u");
106 case 5: return _("%@: syntax error: expected %0e or %1e or %2e or %3e before %u");
107 case 6: return _("%@: syntax error: expected %0e or %1e or %2e or %3e or %4e before %u");
108 case 7: return _("%@: syntax error: expected %0e or %1e or %2e or %3e or %4e or %5e before %u");
109 case 8: return _("%@: syntax error: expected %0e or %1e or %2e or %3e or %4e or %5e or %6e before %u");
113 The message would have to be generated in a string, and pushed to yyerror.
114 Which will be a pain in the neck in yacc.c.
116 If we want to do that, we should think very carefully about the syntax of
119 ** yyclearin does not invoke the lookahead token's %destructor
120 https://lists.gnu.org/r/bug-bison/2018-02/msg00000.html
123 > Modifying yyclearin so that it calls yydestruct seems like the simplest
124 > solution to this issue, but it is conceivable that such a change would
125 > break programs which already perform some kind of workaround in order to
126 > destruct the lookahead symbol. So it might be necessary to use some kind of
127 > compatibility %define, or to create a new replacement macro with a
128 > different name such as yydiscardin.
130 > At a minimum, the fact that yyclearin does not invoke the %destructor
131 > should be highlighted in the documentation, since it is not at all obvious.
135 Les catégories d'avertissements incluent :
136 conflicts-sr conflits S/R (activé par défaut)
137 conflicts-rr conflits R/R (activé par défaut)
138 dangling-alias l'alias chaîne n'est pas attaché à un symbole
139 deprecated construction obsolète
140 empty-rule règle vide sans %empty
141 midrule-values valeurs de règle intermédiaire non définies ou inutilisées
142 precedence priorité et associativité inutiles
143 yacc incompatibilités avec POSIX Yacc
144 other tous les autres avertissements (activé par défaut)
145 all tous les avertissements sauf « dangling-alias » et « yacc »
146 no-CATEGORY désactiver les avertissements dans CATEGORIE
147 none désactiver tous les avertissements
148 error[=CATEGORY] traiter les avertissements comme des erreurs
150 Line -1 and -3 should mention CATEGORIE, not CATEGORY.
154 Get rid of scaffolding in glr.c.
156 ** Unit rules / Injection rules (Akim Demaille)
157 Maybe we could expand unit rules (or "injections", see
158 https://homepages.cwi.nl/~daybuild/daily-books/syntax/2-sdf/sdf.html), i.e.,
167 exp: exp '+' exp | exp '&' exp;
169 when there are no actions. This can significantly speed up some grammars.
170 I can't find the papers. In particular the book 'LR parsing: Theory and
171 Practice' is impossible to find, but according to 'Parsing Techniques: a
172 Practical Guide', it includes information about this issue. Does anybody
175 ** clean up (Akim Demaille)
176 Do not work on these items now, as I (Akim) have branches with a lot of
177 changes in this area (hitting several files), and no desire to have to fix
178 conflicts. Addressing these items will happen after my branches have been
182 Introduce a goto struct, and use it in place of from_state/to_state.
183 Rename states1 as path, length as pathlen.
184 Introduce inline functions for things such as nullable[*rp - ntokens]
185 where we need to map from symbol number to nterm number.
187 There are probably a significant part of the relations management that
188 should be migrated on top of a bitsetv.
191 It should probably take a "state*" instead of two arguments.
194 The "automaton" and "set" categories are not so useful. We should probably
195 introduce lr(0) and lalr, just the way we have ielr categories. The
196 "closure" function is too verbose, it should probably have its own category.
198 "set" can still be used for summarizing the important sets. That would make
199 tests easy to maintain.
202 Rename these guys as "diagnostics.*" (or "diagnose.*"), since that's the
203 name they have in GCC, clang, etc. Likewise for the complain_* series of
207 states/nstates, rules/nrules, ..., ritem/nritems
210 * D programming language
211 There's a number of features that are missing, here sorted in _suggested_
212 order of implementation.
214 When copying code from other skeletons, keep the comments exactly as they
215 are. Keep the same variable names. If you change the wording in one place,
216 do it in the others too. In other words: make sure to keep the
217 maintenance *simple* by avoiding any gratuitous difference.
219 ** Rename the D example
220 Move the current content of examples/d into examples/d/simple.
222 ** Create a second example
223 Duplicate examples/d/simple into examples/d/calc.
225 ** Add location tracking to d/calc
226 Look at the examples in the other languages to see how to do that.
229 The SymbolKind is an enum. For a given SymbolKind we want to get its string
230 representation. Currently it's a separate table in the parser that does
234 public enum SymbolKind
236 S_YYEMPTY = -2, /* No symbol. */
237 S_YYEOF = 0, /* "end of file" */
238 S_YYerror = 1, /* error */
239 S_YYUNDEF = 2, /* "invalid token" */
242 S_input = 14, /* input */
243 S_line = 15, /* line */
244 S_exp = 16, /* exp */
249 /* YYTNAME[SYMBOL-NUM] -- String name of the symbol SYMBOL-NUM.
250 First, the terminals, then, starting at \a yyntokens_, nonterminals. */
251 private static immutable string[] yytname_ =
253 "\"end of file\"", "error", "\"invalid token\"", "\"=\"", "\"+\"",
254 "\"-\"", "\"*\"", "\"/\"", "\"(\"", "\")\"", "\"end of line\"",
255 "\"number\"", "UNARY", "$accept", "input", "line", "exp", null
260 So to get a symbol kind, one runs `yytname_[yykind]`.
262 Is there a way to attach this conversion to string to SymbolKind? In Java
263 for instance, we have:
265 public enum SymbolKind
267 S_YYEOF(0), /* "end of file" */
268 S_YYerror(1), /* error */
269 S_YYUNDEF(2), /* "invalid token" */
271 S_input(16), /* input */
272 S_line(17), /* line */
275 private final int yycode_;
281 /* YYNAMES_[SYMBOL-NUM] -- String name of the symbol SYMBOL-NUM.
282 First, the terminals, then, starting at \a YYNTOKENS_, nonterminals. */
283 private static final String[] yynames_ = yynames_init();
284 private static final String[] yynames_init()
288 i18n("end of file"), i18n("error"), i18n("invalid token"), "!", "+", "-", "*",
289 "/", "^", "(", ")", "=", i18n("end of line"), i18n("number"), "NEG",
290 "$accept", "input", "line", "exp", null
294 /* The user-facing name of this symbol. */
295 public final String getName() {
296 return yynames_[yycode_];
300 which allows to write more naturally `yykind.getName()` rather than
301 `yytname_[yykind]`. Is there something comparable in (idiomatic) D?
303 ** Change the return value of yylex
304 Historically people were allowed to return any int from the scanner (which
305 is convenient and allows `return '+'` from the scanner). Akim tends to see
306 this as an error, we should restrict the return values to TokenKind (not to
307 be confused with SymbolKind).
309 In the case of D, without the history, we have the choice to support or not
310 `int`. If we want to _keep_ `int`, is there a way, say via introspection,
311 to support both signatures of yylex? If we don't keep `int`, just move to
315 Write documentation about D support in doc/bison.texi. Imitate the Java
316 documentation. You should be more succinct IMHO.
319 The current interface from the scanner to the parser is somewhat clumsy: the
320 token kind is returned by yylex, but the value and location are stored in
321 the scanner. This reflects the fact that the implementation of the parser
322 uses three variables to deal with each parsed symbol: its kind, its value,
325 So today the scanner of examples/d/calc.d (no locations) looks like:
327 if (input.front.isNumber)
329 import std.conv : parse;
330 semanticVal_.ival = input.parse!int;
331 return TokenKind.NUM;
334 and the generated parser:
336 /* Read a lookahead token. */
337 if (yychar == TokenKind.YYEMPTY)
340 yylval = yylexer.semanticVal;
343 The parser class should feature a `Symbol` type which binds together kind,
344 value and location, and the scanner should be able to return an instance of
345 that type. Something like
347 if (input.front.isNumber)
349 import std.conv : parse;
350 return parser.Symbol (TokenKind.NUM, input.parse!int);
353 ** Token Constructors
354 In the previous example it is possible to mix incorrectly kinds and values,
357 return parser.Symbol (TokenKind.NUM, "Hello, World!\n");
359 attaches a string value to NUM kind (wrong, of course). When
360 api.token.constructor is set, in C++, Bison generated "token constructors":
361 parser.make_NUM. parser.make_PLUS, parser.make_STRING, etc. The previous
364 return parser.make_NUM ("Hello, World!\n");
366 which would easily be caught by the type checker.
368 ** Lookahead Correction
369 Add support for LAC to the D skeleton. It should not be too hard: look how
370 this is done in lalr1.cc, and mock it.
373 Add support for push parser. Do not start a nice skeleton, just enhance the
374 current one to support push parsers. This is going to be a tougher nut to
377 First, you need to understand well how the push parser is expected to work.
380 - look at examples/c/pushcalc
381 - create an example of a Java push parser.
382 - have a look at the generated parser in Java, which has the advantage of
383 being already based on a parser object, instead of just a function.
385 The C case is harder to read, but it may help too. Keep in mind that
386 because there's no object to maintain state, the C push parser uses some
387 struct (yypstate) to preserve this state. We don't need this in D, the
388 parser object will suffice.
390 I think working directly on the skeleton to add push-parser support is not
391 the simplest path. I suggest that you (1) transform a generated parser into
392 a push parser by hand, and then (2) transform lalr1.d to generate such a
395 Use `git commit` frequently to make sure you keep track of your progress.
397 *** (1.a) Prepare pull parser by hand
398 Copy again one of the D examples into say examples/d/pushcalc. Also
399 check-in the generated parser to facilitate experimentation.
401 - find local variables of yyparse should become members of the parser object
402 (so that we preserve state from one call to the next).
404 - do it in your generated D parser. We don't need an equivalent for
405 yypstate, because we already have it: that the parser object itself.
407 - have your *pull*-parser (i.e., the good old yy::parser::parse()) work
408 properly this way. Write and run tests. That's one of the reasons I
409 suggest using examples/d/calc as a starting point: it already has tests,
410 you can/should add more.
412 At this point you have a pull-parser which you prepared to turn into a
415 *** (1.b) Turn pull parser into push parser by hand
417 - look again at how push parsers are implemented in Java/C to see what needs
418 to change in yyparse so that the control is inverted: parse() will
419 be *given* the tokens, instead of having to call yylex itself. When I say
420 "look at C", I think your best option are (i) yacc.c (look for b4_push_if)
421 and (ii) examples/c/pushcalc.
423 - rename parse() as push_parse(Symbol yyla) (or push_parse(TokenKind, Value,
424 Location)) that takes the symbol as argument. That's the push parser we
427 - define a new parse() function which has the same signature as the usual
428 pull-parser, that repeatedly calls the push_parse function. Something
435 status = this->push_parse (yylex());
436 } while (status == YYPUSH_MORE);
440 - show me that parser, so that we can validate the approach.
442 *** (2) Port that into the skeleton
443 - once we agree on the API of the push parser, implement it into lalr1.d.
444 You will probaby need help on this regard, but imitation, again, should
447 - have example/d/pushcalc work properly and pass tests
449 - add tests in the "real" test suite. Do that in tests/calc.at. I can
455 This is very ambitious. That's the final boss. There are currently no
456 "clean" implementation to get inspiration from.
458 glr.c is very clean but:
460 - is a different skeleton from yacc.c
462 glr.cc is (currently) an ugly hack: a C++ shell around glr.c. Valentin
463 Tolmer is currently rewriting glr.cc to be clean C++, but he is not
464 finished. There will be a lot a common code between lalr1.cc and glr.cc, so
465 eventually I would like them to be fused into a single skeleton, supporting
466 both deterministic and generalized parsing.
468 It would be great for D to also support this.
470 The basic ideas of GLR are explained here:
472 https://www.codeproject.com/Articles/5259825/GLR-Parsing-in-Csharp-How-to-Use-The-Most-Powerful
474 * Better error messages
475 The users are not provided with enough tools to forge their error messages.
476 See for instance "Is there an option to change the message produced by
477 YYERROR_VERBOSE?" by Simon Sobisch, on bison-help.
480 https://www.cs.tufts.edu/~nr/cs257/archive/clinton-jefferey/lr-error-messages.pdf
481 https://research.swtch.com/yyerror
482 http://gallium.inria.fr/~fpottier/publis/fpottier-reachability-cc2016.pdf
485 Fix data/skeletons/yacc.c so that it defines YYPTRDIFF_T properly for modern
486 and older C++ compilers. Currently the code defaults to defining it to
487 'long' for non-GCC compilers, but it should use the proper C++ magic to
488 define it to the same type as the C ptrdiff_t type.
491 Several features are not available in all the back-ends.
493 - lac: D, Java (easy)
494 - push parsers: glr.c, glr.cc, lalr1.cc (not very difficult)
495 - token constructors: Java, C, D (a bit difficult)
496 - glr: D, Java (super difficult)
499 ** Autotest has quotation issues
500 tests/input.at:1730:AT_SETUP([%define errors])
504 $ ./tests/testsuite -l | grep errors | sed q
505 38: input.at:1730 errors
508 ** Get rid of YYPRINT and b4_toknum
509 Besides yytoknum is wrong when api.token.raw is defined.
511 ** Better design for diagnostics
512 The current implementation of diagnostics is ad hoc, it grew organically.
513 It works as a series of calls to several functions, with dependency of the
514 latter calls on the former. For instance:
516 complain (&sym->location,
517 sym->content->status == needed ? complaint : Wother,
518 _("symbol %s is used, but is not defined as a token"
519 " and has no rules; did you mean %s?"),
520 quote_n (0, sym->tag),
521 quote_n (1, best->tag));
522 if (feature_flag & feature_caret)
523 location_caret_suggestion (sym->location, best->tag, stderr);
525 We should rewrite this in a more FP way:
527 1. build a rich structure that denotes the (complete) diagnostic.
528 "Complete" in the sense that it also contains the suggestions, the list
529 of possible matches, etc.
531 2. send this to the pretty-printing routine. The diagnostic structure
532 should be sufficient so that we can generate all the 'format' of
533 diagnostics, including the fixits.
535 If properly done, this diagnostic module can be detached from Bison and be
536 put in gnulib. It could be used, for instance, for errors caught by
539 There's certainly already something alike in GCC. At least that's the
540 impression I get from reading the "-fdiagnostics-format=FORMAT" part of this
543 https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Message-Formatting-Options.html
545 ** Graphviz display code thoughts
546 The code for the --graph option is over two files: print_graph, and
547 graphviz. This is because Bison used to also produce VCG graphs, but since
548 this is no longer true, maybe we could consider these files for fusion.
550 An other consideration worth noting is that print_graph.c (correct me if I
551 am wrong) should contain generic functions, whereas graphviz.c and other
552 potential files should contain just the specific code for that output
553 format. It will probably prove difficult to tell if the implementation is
554 actually generic whilst only having support for a single format, but it
555 would be nice to keep stuff a bit tidier: right now, the construction of the
556 bitset used to show reductions is in the graphviz-specific code, and on the
557 opposite side we have some use of \l, which is graphviz-specific, in what
558 should be generic code.
560 Little effort seems to have been given to factoring these files and their
561 print{,-xml} counterpart. We would very much like to re-use the pretty format
562 of states from .output for the graphs, etc.
564 Since graphviz dies on medium-to-big grammars, maybe consider an other tool?
567 Check it too when checking the different kinds of parsers. And be
568 sure to check that the initial-action is performed once per parsing.
571 b4_shared_declarations is no longer what it is. Make it
572 b4_parser_declaration for instance.
574 ** yychar in lalr1.cc
575 There is a large difference bw maint and master on the handling of
576 yychar (which was removed in lalr1.cc). See what needs to be
580 /* User semantic actions sometimes alter yychar, and that requires
581 that yytoken be updated with the new translation. We take the
582 approach of translating immediately before every use of yytoken.
583 One alternative is translating here after every semantic action,
584 but that translation would be missed if the semantic action
585 invokes YYABORT, YYACCEPT, or YYERROR immediately after altering
586 yychar. In the case of YYABORT or YYACCEPT, an incorrect
587 destructor might then be invoked immediately. In the case of
588 YYERROR, subsequent parser actions might lead to an incorrect
589 destructor call or verbose syntax error message before the
590 lookahead is translated. */
592 /* Make sure we have latest lookahead translation. See comments at
593 user semantic actions for why this is necessary. */
594 yytoken = yytranslate_ (yychar);
597 ** Get rid of fake #lines [Bison: ...]
598 Possibly as simple as checking whether the column number is nonnegative.
600 I have seen messages like the following from GCC.
602 <built-in>:0: fatal error: opening dependency file .deps/libltdl/argz.Tpo: No such file or directory
605 ** Discuss about %printer/%destroy in the case of C++.
606 It would be very nice to provide the symbol classes with an operator<<
607 and a destructor. Unfortunately the syntax we have chosen for
608 %destroy and %printer make them hard to reuse. For instance, the user
609 is invited to write something like
611 %printer { debug_stream() << $$; } <my_type>;
613 which is hard to reuse elsewhere since it wants to use
614 "debug_stream()" to find the stream to use. The same applies to
615 %destroy: we told the user she could use the members of the Parser
616 class in the printers/destructors, which is not good for an operator<<
617 since it is no longer bound to a particular parser, it's just a
621 ** Rewrite glr.cc in C++ (Valentin Tolmer)
622 As a matter of fact, it would be very interesting to see how much we can
623 share between lalr1.cc and glr.cc. Most of the skeletons should be common.
624 It would be a very nice source of inspiration for the other languages.
626 Valentin Tolmer is working on this.
629 The code in yyerrlab reads:
633 /* Return failure if at end of input. */
638 There are only two yychar that can be <= YYEOF: YYEMPTY and YYEOF.
639 But I can't produce the situation where yychar is YYEMPTY here, is it
640 really possible? The test suite does not exercise this case.
642 This shows that it would be interesting to manage to install skeleton
643 coverage analysis to the test suite.
645 * From lalr1.cc to yacc.c
647 Merging the three stacks in lalr1.cc simplified the code, prompted for
648 other improvements and also made it faster (probably because memory
649 management is performed once instead of three times). I suggest that
650 we do the same in yacc.c.
652 (Some time later): it's also very nice to have three stacks: it's more dense
653 as we don't lose bits to padding. For instance the typical stack for states
654 will use 8 bits, while it is likely to consume 32 bits in a struct.
656 We need trustworthy benchmarks for Bison, for all our backends. Akim has a
657 few things scattered around; we need to put them in the repo, and make them
663 Some statistics about the grammar and the parser would be useful,
664 especially when asking the user to send some information about the
665 grammars she is working on. We should probably also include some
666 information about the variables (I'm not sure for instance we even
667 specify what LR variant was used).
670 How would Paul like to display the conflicted actions? In particular,
671 what when two reductions are possible on a given lookahead token, but one is
672 part of $default. Should we make the two reductions explicit, or just
673 keep $default? See the following point.
675 ** Disabled Reductions
676 See 'tests/conflicts.at (Defaulted Conflicted Reduction)', and decide
680 Extend with error productions. The hard part will probably be finding
681 the right rule so that a single state does not exhibit too many yet
682 undocumented ''features''. Maybe an empty action ought to be
683 presented too. Shall we try to make a single grammar with all these
684 features, or should we have several very small grammars?
688 Well, only if there is really some demand for it.
691 https://github.com/scfc/bison-php/blob/master/data/lalr1.php
694 https://lists.gnu.org/r/bison-patches/2013-09/msg00000.html and following
696 ** Multiple start symbols
697 Would be very useful when parsing closely related languages. The idea is to
698 declare several start symbols, for instance
705 and to generate parse(), parse_stmt() and parse_expr(). Technically, the
706 above grammar would be transformed into
709 %token YY_START_STMT YY_START_EXPR
711 yy_start: YY_START_STMT stmt | YY_START_EXPR expr
713 so that there are no new conflicts in the grammar (as would undoubtedly
714 happen with yy_start: stmt | expr). Then adjust the skeletons so that this
715 initial token (YY_START_STMT, YY_START_EXPR) be shifted first in the
716 corresponding parse function.
719 This is a popular demand. We already made many changes in the parser that
720 should make this reasonably easy to implement.
722 Bruce Mardle <marblypup@yahoo.co.uk>
723 https://lists.gnu.org/archive/html/bison-patches/2015-09/msg00000.html
725 However, there are many other things to do before having such a feature,
726 because I don't want a % equivalent to #include (which we all learned to
727 hate). I want something that builds "modules" of grammars, and assembles
728 them together, paying attention to keep separate bits separated, in pseudo
732 There is demand for push parsers in Java and C++. And GLR I guess.
734 ** Generate code instead of tables
735 This is certainly quite a lot of work. See
736 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.50.4539.
739 We should find a means to provide an access to values deep in the
740 stack. For instance, instead of
742 baz: qux { $$ = $<foo>-1 + $<bar>0 + $1; }
744 we should be able to have:
746 foo($foo) bar($bar) baz($bar): qux($qux) { $baz = $foo + $bar + $qux; }
748 Or something like this.
751 It should be possible to have %if/%else/%endif. The implementation is
752 not clear: should it be lexical or syntactic. Vadim Maslow thinks it
753 must be in the scanner: we must not parse what is in a switched off
754 part of %if. Akim Demaille thinks it should be in the parser, so as
755 to avoid falling into another CPP mistake.
757 (Later): I'm sure there's actually good case for this. People who need that
758 feature can use m4/cpp on top of Bison. I don't think it is worth the
759 trouble in Bison itself.
762 There are couple of available extensions of Bison targeting some XML
763 output. Some day we should consider including them. One issue is
764 that they seem to be quite orthogonal to the parsing technique, and
765 seem to depend mostly on the possibility to have some code triggered
766 for each reduction. As a matter of fact, such hooks could also be
767 used to generate the yydebug traces. Some generic scheme probably
770 XML output for GNU Bison and gcc
771 http://www.cs.may.ie/~jpower/Research/bisonXML/
773 XML output for GNU Bison
774 http://yaxx.sourceforge.net/
776 * Coding system independence
779 Currently Bison assumes 8-bit bytes (i.e. that UCHAR_MAX is
780 255). It also assumes that the 8-bit character encoding is
781 the same for the invocation of 'bison' as it is for the
782 invocation of 'cc', but this is not necessarily true when
783 people run bison on an ASCII host and then use cc on an EBCDIC
784 host. I don't think these topics are worth our time
785 addressing (unless we find a gung-ho volunteer for EBCDIC or
786 PDP-10 ports :-) but they should probably be documented
789 More importantly, Bison does not currently allow NUL bytes in
790 tokens, either via escapes (e.g., "x\0y") or via a NUL byte in
791 the source code. This should get fixed.
796 Must we keep %token-table?
801 It is unfortunate that there is a total order for precedence. It
802 makes it impossible to have modular precedence information. We should
803 move to partial orders (sounds like series/parallel orders to me).
805 This is a prerequisite for modules.
807 * Pre and post actions.
808 From: Florian Krohm <florian@edamail.fishkill.ibm.com>
809 Subject: YYACT_EPILOGUE
810 To: bug-bison@gnu.org
811 X-Sent: 1 week, 4 days, 14 hours, 38 minutes, 11 seconds ago
813 The other day I had the need for explicitly building the parse tree. I
814 used %locations for that and defined YYLLOC_DEFAULT to call a function
815 that returns the tree node for the production. Easy. But I also needed
816 to assign the S-attribute to the tree node. That cannot be done in
817 YYLLOC_DEFAULT, because it is invoked before the action is executed.
818 The way I solved this was to define a macro YYACT_EPILOGUE that would
819 be invoked after the action. For reasons of symmetry I also added
820 YYACT_PROLOGUE. Although I had no use for that I can envision how it
821 might come in handy for debugging purposes.
822 All is needed is to add
825 YYACT_EPILOGUE (yyval, (yyvsp - yylen), yylen, yyloc, (yylsp - yylen));
827 YYACT_EPILOGUE (yyval, (yyvsp - yylen), yylen);
830 at the proper place to bison.simple. Ditto for YYACT_PROLOGUE.
832 I was wondering what you think about adding YYACT_PROLOGUE/EPILOGUE
833 to bison. If you're interested, I'll work on a patch.
836 Equip the parser with a means to create the (visual) parse tree.
841 # LocalWords: Cex gnulib gl Bistromathic TokenKinds yylex enum YYEOF EOF
842 # LocalWords: YYerror gettext af hb YYERRCODE undef calc FIXME dev yyerror
843 # LocalWords: Autoconf YYUNDEFTOK lexemes parsers Bistromathic's yyreport
844 # LocalWords: const argc yacc yyclearin lookahead destructor Rici incluent
845 # LocalWords: yydestruct yydiscardin catégories d'avertissements sr activé
846 # LocalWords: conflits défaut rr l'alias chaîne n'est attaché un symbole
847 # LocalWords: obsolète règle vide midrule valeurs de intermédiaire ou avec
848 # LocalWords: définies inutilisées priorité associativité inutiles POSIX
849 # LocalWords: incompatibilités tous les autres avertissements sauf dans rp
850 # LocalWords: désactiver CATEGORIE traiter comme des erreurs glr Akim bool
851 # LocalWords: Demaille arith lalr goto struct pathlen nullable ntokens lr
852 # LocalWords: nterm bitsetv ielr ritem nstates nrules nritems yysymbol EQ
853 # LocalWords: SymbolKind YYEMPTY YYUNDEF YYTNAME NUM yyntokens yytname sed
854 # LocalWords: nonterminals yykind yycode YYNAMES yynames init getName conv
855 # LocalWords: TokenKind semanticVal ival yychar yylval yylexer Tolmer hoc
856 # LocalWords: Sobisch YYPTRDIFF ptrdiff Autotest YYPRINT toknum yytoknum
857 # LocalWords: sym Wother stderr FP fixits xgettext fdiagnostics Graphviz
858 # LocalWords: graphviz VCG bitset xml bw maint yytoken YYABORT deps
859 # LocalWords: YYACCEPT yytranslate nonnegative destructors yyerrlab repo
860 # LocalWords: backends stmt expr yy Mardle baz qux Vadim Maslow CPP cpp
861 # LocalWords: yydebug gcc UCHAR EBCDIC gung PDP NUL Pre Florian Krohm utf
862 # LocalWords: YYACT YYLLOC YYLSP yyval yyvsp yylen yyloc yylsp endif
863 # LocalWords: ispell american
869 ispell-dictionary: "american"
872 Copyright (C) 2001-2004, 2006, 2008-2015, 2018-2020 Free Software
875 This file is part of Bison, the GNU Compiler Compiler.
877 Permission is granted to copy, distribute and/or modify this document
878 under the terms of the GNU Free Documentation License, Version 1.3 or
879 any later version published by the Free Software Foundation; with no
880 Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
881 Texts. A copy of the license is included in the "GNU Free
882 Documentation License" file as part of this distribution.