Sharing a project built on Lark in case it's a useful real-world Earley example.

[stzifkas]

pluto-ecss transpiles PLUTO - a spacecraft operations DSL standardised by ESA (ECSS-E-ST-70-32C) - into readable Python.

The grammar's defining challenge is unquoted multi-word identifiers ("Reaction Wheel3 of AOC of Satellite") coexisting with English-word keywords, which I handle with a low-priority catch-all WORD terminal (priority -10) so keyword literals always win, plus rule-level assembly of identifiers.

Along the way I hit — and worked around — an Earley lexer-priority edge case that might be interesting to you. Grammar is 168 lines and self-contained:
https://github.com/stzifkas/pluto-ecss/blob/main/src/pluto_ecss/grammar.lark

Thanks for Lark! the Earley/dynamic-lexer combo is what made this DSL tractable at all. Happy to be listed as an example project if that's useful to others.

[erezsh]

Thanks!

the Earley/dynamic-lexer combo is what made this DSL tractable at all

You mean, because of performance issues?

[stzifkas]

it's the opposite of a performance thing. If anything Earley is the slower choice. LALR would be faster. "Tractable" there means parseable at all without brittle hacks, not fast.

The problem is ambiguity, not speed. PLUTO identifiers are unquoted and multi-word (Reaction Wheel3 of AOC of Satellite), and they collide with keywords (of, in, and, until…). With a traditional setup (LALR + a static lexer that tokenizes the whole input up front) the lexer has to decide "is this word a keyword or part of a name?" before the parser has any context to say which is correct. That's what forced my initial grammar into negative-lookahead regexes, and those break the moment a real procedure uses a keyword-ish English word inside a name.

[erezsh]

I see. Yes, Earley is a great algorithm. I'm glad it helped your use-case!