_____________________________________________________________________________
Immediately
-- If a top-level rule has labels but no head-tag, like this
- Foo = a:Bar b:Baz
- then infer the name of the rule it belongs to
+ - Sequence shouldn't be an Element -> make Union.add(Element)
+ - Should Tree<T> really be type-parameterized?
-create( $c:{...}, class ) =
- return create($c:{...})
+ - More topology untangling
+ - needs/hates/follow API ugliness
-create( h:{...}, class ) =
-
-create( , String)
-
-create( _:{...}, String) = treat as char[]
-create( _:{...}, c[] ) = { create(.,c), create(.,c), ... }
-
-create( $c:{...} ) =
-
-
- - clean up the visualization (?)
-
- - I still don't like Atom.Infer and Atom.Invert...
-
- - better ambiguity debugging tools
+ - do Forest/Tree still need a Region?
+ - reconsider the degree of genericization
+ - GraphViz stuff pollutes the API...
+ - Forest needs a "manual access" API
+ - the unwrap bit in Forest makes it really hard to expose an API for forests
+ - evil problems with (x y? z /ws)
- ParseFailed, GSS, Walk, Parser, Sequence, Forest
-
- - Fix the metagrammar (really?)
- - evil problems with (x y? z /ws)
-
- copyright notices
- documentation
+ - grammar highlighting?
+ - comment indentation vs block indentation?
+ - { and } in <pre>
+ - recursive { { foo } }
+
______________________________________________________________________________
v1.1
- RFC2822 (email message/headers)
- clean up the whole Walk situation (?)
- - what if Tree<> could unwrap itself?
-
______________________________________________________________________________
Soon
- eliminated statically?
- substring parsing for better error messages
- - "lift" cases:
- - right now I can only lift the last child in a forest... begs
- the question of what the right representation for Forests is
- if we need to be able to do lift operations on it.
- Parameterized LR
- "Regular Right Part" grammars (NP Chapman, etc)
projects / sbp.git / blobdiff