TODO

   1 -*- outline -*-
   2
   3 * Header guards
   4
   5 From Franc,ois: should we keep the directory part in the CPP guard?
   6
   7
   8 * Yacc.c: CPP Macros
   9
  10 Do some people use YYPURE, YYLSP_NEEDED like we do in the test suite?
  11 They should not: it is not documented.  But if they need to, let's
  12 find something clean (not like YYLSP_NEEDED...).
  13
  14
  15 * Installation
  16
  17 * Documentation
  18 Before releasing, make sure the documentation ("Understanding your
  19 parser") refers to the current `output' format.
  20
  21 * lalr1.cc
  22 ** vector
  23 Move to using vector, drop stack.hh.
  24
  25 * Report
  26
  27 **  GLR
  28 How would Paul like to display the conflicted actions?  In particular,
  29 what when two reductions are possible on a given lookahead token, but one is
  30 part of $default.  Should we make the two reductions explicit, or just
  31 keep $default?  See the following point.
  32
  33 ** Disabled Reductions
  34 See `tests/conflicts.at (Defaulted Conflicted Reduction)', and decide
  35 what we want to do.
  36
  37 ** Documentation
  38 Extend with error productions.  The hard part will probably be finding
  39 the right rule so that a single state does not exhibit too many yet
  40 undocumented ``features''.  Maybe an empty action ought to be
  41 presented too.  Shall we try to make a single grammar with all these
  42 features, or should we have several very small grammars?
  43
  44 ** --report=conflict-path
  45 Provide better assistance for understanding the conflicts by providing
  46 a sample text exhibiting the (LALR) ambiguity.  See the paper from
  47 DeRemer and Penello: they already provide the algorithm.
  48
  49 ** Statically check for potential ambiguities in GLR grammars.  See
  50 <http://www.i3s.unice.fr/~schmitz/papers.html#expamb> for an approach.
  51
  52
  53 * Extensions
  54
  55 ** $-1
  56 We should find a means to provide an access to values deep in the
  57 stack.  For instance, instead of
  58
  59         baz: qux { $$ = $<foo>-1 + $<bar>0 + $1; }
  60
  61 we should be able to have:
  62
  63   foo($foo) bar($bar) baz($bar): qux($qux) { $baz = $foo + $bar + $qux; }
  64
  65 Or something like this.
  66
  67 ** %if and the like
  68 It should be possible to have %if/%else/%endif.  The implementation is
  69 not clear: should it be lexical or syntactic.  Vadim Maslow thinks it
  70 must be in the scanner: we must not parse what is in a switched off
  71 part of %if.  Akim Demaille thinks it should be in the parser, so as
  72 to avoid falling into another CPP mistake.
  73
  74 ** -D, --define-muscle NAME=VALUE
  75 To define muscles via cli.  Or maybe support directly NAME=VALUE?
  76
  77 ** XML Output
  78 There are couple of available extensions of Bison targeting some XML
  79 output.  Some day we should consider including them.  One issue is
  80 that they seem to be quite orthogonal to the parsing technique, and
  81 seem to depend mostly on the possibility to have some code triggered
  82 for each reduction.  As a matter of fact, such hooks could also be
  83 used to generate the yydebug traces.  Some generic scheme probably
  84 exists in there.
  85
  86 XML output for GNU Bison and gcc
  87    http://www.cs.may.ie/~jpower/Research/bisonXML/
  88
  89 XML output for GNU Bison
  90    http://yaxx.sourceforge.net/
  91
  92 * Unit rules
  93 Maybe we could expand unit rules, i.e., transform
  94
  95         exp: arith | bool;
  96         arith: exp '+' exp;
  97         bool: exp '&' exp;
  98
  99 into
 100
 101         exp: exp '+' exp | exp '&' exp;
 102
 103 when there are no actions.  This can significantly speed up some
 104 grammars.  I can't find the papers.  In particular the book `LR
 105 parsing: Theory and Practice' is impossible to find, but according to
 106 `Parsing Techniques: a Practical Guide', it includes information about
 107 this issue.  Does anybody have it?
 108
 109
 110
 111 * Documentation
 112
 113 ** History/Bibliography
 114 Some history of Bison and some bibliography would be most welcome.
 115 Are there any Texinfo standards for bibliography?
 116
 117
 118
 119 * Java, Fortran, etc.
 120
 121
 122 * Coding system independence
 123 Paul notes:
 124
 125         Currently Bison assumes 8-bit bytes (i.e. that UCHAR_MAX is
 126         255).  It also assumes that the 8-bit character encoding is
 127         the same for the invocation of 'bison' as it is for the
 128         invocation of 'cc', but this is not necessarily true when
 129         people run bison on an ASCII host and then use cc on an EBCDIC
 130         host.  I don't think these topics are worth our time
 131         addressing (unless we find a gung-ho volunteer for EBCDIC or
 132         PDP-10 ports :-) but they should probably be documented
 133         somewhere.
 134
 135         More importantly, Bison does not currently allow NUL bytes in
 136         tokens, either via escapes (e.g., "x\0y") or via a NUL byte in
 137         the source code.  This should get fixed.
 138
 139 * --graph
 140 Show reductions.
 141
 142 * Broken options ?
 143 ** %token-table
 144 ** Skeleton strategy
 145 Must we keep %token-table?
 146
 147 * src/print_graph.c
 148 Find the best graph parameters.
 149
 150 * BTYacc
 151 See if we can integrate backtracking in Bison.  Charles-Henri de
 152 Boysson <de-boy_c@epita.fr> is working on this, and already has some
 153 results.  Vadim Maslow, the maintainer of BTYacc was contacted, and we
 154 stay in touch with him.  Adjusting the Bison grammar parser will be
 155 needed to support some extra BTYacc features.  This is less urgent.
 156
 157 ** Keeping the conflicted actions
 158 First, analyze the differences between byacc and btyacc (I'm referring
 159 to the executables).  Find where the conflicts are preserved.
 160
 161 ** Compare with the GLR tables
 162 See how isomorphic the way BTYacc and the way the GLR adjustments in
 163 Bison are compatible.  *As much as possible* one should try to use the
 164 same implementation in the Bison executables.  I insist: it should be
 165 very feasible to use the very same conflict tables.
 166
 167 ** Adjust the skeletons
 168 Import the skeletons for C and C++.
 169
 170 ** Improve the skeletons
 171 Have them support yysymprint, yydestruct and so forth.
 172
 173
 174 * Precedence
 175
 176 ** Partial order
 177 It is unfortunate that there is a total order for precedence.  It
 178 makes it impossible to have modular precedence information.  We should
 179 move to partial orders (sounds like series/parallel orders to me).
 180
 181 ** Correlation b/w precedence and associativity
 182 Also, I fail to understand why we have to assign the same
 183 associativity to operators with the same precedence.  For instance,
 184 why can't I decide that the precedence of * and / is the same, but the
 185 latter is nonassoc?
 186
 187 If there is really no profound motivation, we should find a new syntax
 188 to allow specifying this.
 189
 190 ** RR conflicts
 191 See if we can use precedence between rules to solve RR conflicts.  See
 192 what POSIX says.
 193
 194
 195 * $undefined
 196 From Hans:
 197 - If the Bison generated parser experiences an undefined number in the
 198 character range, that character is written out in diagnostic messages, an
 199 addition to the $undefined value.
 200
 201 Suggest: Change the name $undefined to undefined; looks better in outputs.
 202
 203
 204 * Default Action
 205 From Hans:
 206 - For use with my C++ parser, I transported the "switch (yyn)" statement
 207 that Bison writes to the bison.simple skeleton file. This way, I can remove
 208 the current default rule $$ = $1 implementation, which causes a double
 209 assignment to $$ which may not be OK under C++, replacing it with a
 210 "default:" part within the switch statement.
 211
 212 Note that the default rule $$ = $1, when typed, is perfectly OK under C,
 213 but in the C++ implementation I made, this rule is different from
 214 $<type_name>$ = $<type_name>1. I therefore think that one should implement
 215 a Bison option where every typed default rule is explicitly written out
 216 (same typed ruled can of course be grouped together).
 217
 218 Note: Robert Anisko handles this.  He knows how to do it.
 219
 220
 221 * Warnings
 222 It would be nice to have warning support.  See how Autoconf handles
 223 them, it is fairly well described there.  It would be very nice to
 224 implement this in such a way that other programs could use
 225 lib/warnings.[ch].
 226
 227 Don't work on this without first announcing you do, as I already have
 228 thought about it, and know many of the components that can be used to
 229 implement it.
 230
 231
 232 * Pre and post actions.
 233 From: Florian Krohm <florian@edamail.fishkill.ibm.com>
 234 Subject: YYACT_EPILOGUE
 235 To: bug-bison@gnu.org
 236 X-Sent: 1 week, 4 days, 14 hours, 38 minutes, 11 seconds ago
 237
 238 The other day I had the need for explicitly building the parse tree. I
 239 used %locations for that and defined YYLLOC_DEFAULT to call a function
 240 that returns the tree node for the production. Easy. But I also needed
 241 to assign the S-attribute to the tree node. That cannot be done in
 242 YYLLOC_DEFAULT, because it is invoked before the action is executed.
 243 The way I solved this was to define a macro YYACT_EPILOGUE that would
 244 be invoked after the action. For reasons of symmetry I also added
 245 YYACT_PROLOGUE. Although I had no use for that I can envision how it
 246 might come in handy for debugging purposes.
 247 All is needed is to add
 248
 249 #if YYLSP_NEEDED
 250     YYACT_EPILOGUE (yyval, (yyvsp - yylen), yylen, yyloc, (yylsp - yylen));
 251 #else
 252     YYACT_EPILOGUE (yyval, (yyvsp - yylen), yylen);
 253 #endif
 254
 255 at the proper place to bison.simple. Ditto for YYACT_PROLOGUE.
 256
 257 I was wondering what you think about adding YYACT_PROLOGUE/EPILOGUE
 258 to bison. If you're interested, I'll work on a patch.
 259
 260 * Better graphics
 261 Equip the parser with a means to create the (visual) parse tree.
 262
 263 -----
 264
 265 Copyright (C) 2001-2004, 2006, 2008-2012 Free Software Foundation, Inc.
 266
 267 This file is part of Bison, the GNU Compiler Compiler.
 268
 269 This program is free software: you can redistribute it and/or modify
 270 it under the terms of the GNU General Public License as published by
 271 the Free Software Foundation, either version 3 of the License, or
 272 (at your option) any later version.
 273
 274 This program is distributed in the hope that it will be useful,
 275 but WITHOUT ANY WARRANTY; without even the implied warranty of
 276 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 277 GNU General Public License for more details.
 278
 279 You should have received a copy of the GNU General Public License
 280 along with this program.  If not, see <http://www.gnu.org/licenses/>.