TODO

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