gll
gll copied to clipboard
rust-lang
GLL parsing framework.
Allow defining rules that expand based on parameters - we can start off with something like this: ```rust eq(x, x) = {}; Expr(allow_ident_left, allow_ident_right) = { eq(allow_ident_left, "1") eq(allow_ident_right, "1")...
That is, replace something like this (`A | B | C` would be a parse/code label): ```rust struct Graph { children: Map, } ``` to be more like this: ```rust...
These two are isomorphic: ```rust { code: constant, state: per-arm } { code: per-arm, state: constant } ``` So we should be generating more code instead of trying to keep...
With the current (breadth-first) evaluation strategy, we can use the union of the input ranges of all the scheduler entries as a conservative approximation of the range of the input...
If we know the length of a terminal, e.g. the `"and"` in `X "and" Y`, then we can rely on that to make `X "and"` not record its split in...
Right now only "forward" parsing is supported but some infrastructure exists for "backward" parsing. Everything is the same except: * `A B` changes order * lookahead turns into lookbehind and...
See https://github.com/rust-lang/rust/issues/47575#issuecomment-367493905 for my old implementation. A generalized `SparseBitMatrix` could allow "`Row`" to be anything, with the "`Column`" remaining restricted to a "newtyped index" (integer), by having the representation: ```rust...
The `.then` and `or` methods could be `+` and `|` overloaded operators. Similarly, `%` could be used to turn `X*` into `X* % Y`.
Given a `WS` rule, convert e.g. `A+ B {C* % ","} D` to `{A+ % WS} WS B WS {C* % {WS "," WS}} WS D`.