TODO

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