-
Currently, the engine only implements the Earley recognizer algorithm. It *might* be better to implement the full parser.
Pros:
- Directly provide the AST to the user
Cons:
- In most cases the…
-
Below are two simple grammars. The first one produces 2 identical derivations, and the second one produces 4 identical derivations.
@chanicpanic If you have the time, maybe you could take a look? I…
-
Since lark version 1.2.1, there seem to be (more?) ambiguities produced for our syntax.
While the syntax is ambiguous, we used prioritiies to fix this before.
```
%import common.INT
%import comm…
-
I was wondering, would it be straightforward to get Earley and Reconstructor in Lark.js as well? If it can help, I'd be happy to contribute.
-
Thanks for Lerche.jl, it looks great.
The Python Lark supports also Earley(SPPF) parsing. Any plans to implement this also for Lerche.jl?
-
Need to implement the Leo Optimization for the Earley parser to optimize right-recursive rules.
I'm not attaching this one to a milestone. I think we can release 3.1.0 without it, but it would be …
-
I'm getting the error `Dynamic Earley doesn't support weights on terminals` when I try to compile _humanized_opening_hours_
This should come from https://github.com/lark-parser/lark/issues/383
-
Currently we have `builtins.match` for parsing strings using regular expressions. Perhaps it would be appropriate to also have `builtins.earley` function that takes an ABNF (or EBNF) grammar and a str…
-
CUrrently the `earley` parser is used which is very slow (~20min for 1300 instr.). In order to use the significantly faster `lalr` parser the priorities of the terminals must be set correctly.
-
I made an Earley engine that is much faster in benchmarks than YAEP: [gearley](https://github.com/pczarn/gearley). Here are the results for 88248 tokens (10K lines of C).
```
gearley: bench_parse_c …