TODO

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