TODO

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