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