TODO

   1 _____________________________________________________________________________
   2 Immediately
   3
   4 - If a top-level rule has labels but no head-tag, like this
   5     Foo = a:Bar b:Baz
   6   then infer the name of the rule it belongs to
   7
   8 create( $c:{...}, class ) =
   9   return create($c:{...})
  10
  11 create( h:{...}, class ) =
  12
  13 create( , String)
  14
  15 create( _:{...}, String) = treat as char[]
  16 create( _:{...}, c[] )   = { create(.,c), create(.,c), ... }
  17
  18 create( $c:{...} ) =
  19
  20
  21   - better ambiguity debugging tools / visualization
  22
  23   - ParseFailed, GSS, Walk, Parser, Sequence, Forest
  24
  25   - Fix the metagrammar (really?)
  26       - evil problems with      (x y? z /ws)
  27
  28   - copyright notices
  29   - documentation
  30
  31 ______________________________________________________________________________
  32 v1.1
  33
  34   - finalize metagrammar and rdp-op's
  35   - write some grammars
  36       - Java grammar
  37       - TeX (math?)
  38       - URL (RFC)
  39       - RFC2822 (email message/headers)
  40   - clean up the whole Walk situation (?)
  41
  42   - what if Tree<> could unwrap itself?
  43
  44
  45 ______________________________________________________________________________
  46 Soon
  47
  48   - serialization of parse tables
  49
  50   - "ambiguity modulo dropped fragments"?
  51        - can this be checked statically?
  52        - eliminated statically?
  53
  54   - substring parsing for better error messages
  55   - "lift" cases:
  56       - right now I can only lift the last child in a forest...  begs
  57         the question of what the right representation for Forests is
  58         if we need to be able to do lift operations on it.
  59
  60   - Parameterized LR
  61   - "Regular Right Part" grammars (NP Chapman, etc)
  62   - Attribute unification
  63
  64   - inference of rejections for literals
  65   - "prefer whitespace higher up" (?)
  66
  67   - Labeled edges on trees (associate a label with each slot in the
  68     child array in Forest.Body?  might make equality tough) --
  69     equivalent to Feature Structures.  Colon-labeling.
  70
  71 ______________________________________________________________________________
  72 Later
  73
  74   - Partly-Linear-PATR? (O(n^6) unification grammar)
  75
  76   - Implement a k-token peek buffer (for each state, see if it "dead
  77     ends" during the next k Phases based solely on state -- ignoring
  78     result SPPF)
  79
  80   - Arrange for the SPPF corresponding to dropped subtrees to never be
  81     generated (or merged, etc)
  82
  83   - Is there any way we can avoid creating a GSS.Node instance for
  84     nodes which are transient in the sense that they have only one
  85     eligible reduction?
  86
  87   - Re-read Rekers, particularly the stuff on optimal sharing
  88
  89   - Isolate the Element objects from Parse.Table/GSS so we can move
  90     towards compilation.
  91
  92   - consider allowing a Forest.Body to represent some other Tree whose
  93     Body's should be [recursively] considered part of this Forest.
  94
  95       - perhaps not: right now we have a nice situation where
  96         Forest.Ref instances become immutable once iterator()ed.  This
  97         also gives us a strong place to to culling with the certainty
  98         that we won't throw out a Body which would later be salvaged
  99         by some yet-to-be-added dependency.
 100
 101   - Figure out if there is a way to:
 102
 103       - allow unwrapping of children other than the very last one.
 104
 105       - fold repetitions into an array form in Forest, before
 106         conversion to Tree.  The major problem here is that multiple
 107         tree-arrays are possible, all of different lengths.  Worse,
 108         even if they're all the same length, not all elements belong
 109         in the same "possibility vector" as all others.  You
 110         essentially need a GSS to represent the array, which perhaps
 111         is what the unfolded form was in the first place.
 112
 113   - Wikipedia grammar (needs to be both lexerless and boolean)
 114
 115   - Boolean Parsing
 116       => Ordered Choice (";" operator)
 117
 118   - bring back in parse-table phase resolution of precedence (just
 119     like associativity).  This can be inferred from the use of ">"
 120     when the rules are in one of these special forms:
 121
 122        E ::=  E     _
 123            >  _     E
 124
 125        E ::=  _     E
 126            >  E  _  E
 127
 128        E ::=  E  _  E
 129            >  E  _  E
 130
 131     where "_" is anything and "E" is the defining nonterminal.
 132     Essentially what we're looking for is the situation where the
 133     leftmost portion of one rule produces another rule, and the
 134     rightmost portion of the latter produces the former.
 135
 136     I'm not 100% certain that this is as "strong" as the prefer/avoid
 137     form (try to prove this, you probably can), but it's "what people
 138     intend" most of the time.
 139
 140   - implement Johnstone's algorithm for "reduced, resolved LR
 141     tables" to eliminate superfluous reductions on
 142     epsilon-transitions.
 143
 144 ______________________________________________________________________________
 145 Neat Ideas
 146
 147   - Rekers & Koorn note that GLR Substring Parsing can be used to do
 148     really elegant and generalized "autocompletion".
 149
 150
 151 ______________________________________________________________________________
 152 Ideas for the Future
 153
 154 - Incremental parse table construction
 155 - "lazy GLR" and "lazy trees" -> language with first-class CF matching
 156     - perhaps linear boolean grammars instead? (linear time, quad space)
 157 - Forest parsing => chained parsers
 158 - unification parsing, attributes, etc
 159 - RRP grammars?
 160 - Take another stab at maximal-match?  Nonterminal not-followed-by is
 161   too strong.
 162 - Error recovery based on substring parsing