TODO

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