TODO

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