TODO

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