Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lark grammar? #391

Open
davaya opened this issue May 28, 2019 · 8 comments · May be fixed by #1388
Open

Lark grammar? #391

davaya opened this issue May 28, 2019 · 8 comments · May be fixed by #1388
Labels
discussion Discuss new features or other changes
Milestone

Comments

@davaya
Copy link
Contributor

davaya commented May 28, 2019

Are there any plans to create a Lark grammar for Lark? The only file currently in lark/grammars is common.lark, which defines a few terminals.

The authoritative definition of Lark would logically be expressed as a grammar (as opposed to "what the grammar reference says" or "what the latest version of the code parses"). Note that RFC 5234 defines the ABNF grammar that authoritatively validates ABNF specifications.

@erezsh
Copy link
Member

erezsh commented May 28, 2019

There is a reference-quality grammar in ./examples: https://github.com/lark-parser/lark/blob/master/examples/lark.lark

Do you think there is a benefit to making it formal?

@MegaIng
Copy link
Member

MegaIng commented Jun 28, 2019

Yes, I think there should be a formal lark-grammar for lark. Mainly, so that I can apply it to the intellij-plugin I am developing and the theoretically planed linter I think about developing.

@erezsh
Copy link
Member

erezsh commented Jun 28, 2019

Well, you can already use the grammar I linked to. It's correct and fairly comprehensive.

@erezsh erezsh added the discussion Discuss new features or other changes label Jul 1, 2019
@erezsh erezsh added this to the v1.0 milestone Sep 13, 2020
@RossPatterson
Copy link

There are some things in lark.lark that don't match what load_grammar.py implements. For example, I learned the hard way that load_grammar only allows rule aliases on top-level alternates, although lark.lark says they're valid on alternates at any depth. Another example is that lark.lark says "%ignore" expansions, but load_grammar requires that expansions be derived as expansions -> expansion -> value -> Terminal.

@erezsh
Copy link
Member

erezsh commented Jan 29, 2024

You're welcome to submit a PR that fixes lark.lark

@RossPatterson
Copy link

Sounds good. I wasn't sure which version was definitive. So, basically the loader is correct and the grammar should reflect what it does, right?

While I'm at it, I'll take a look at the grammar reference documentation and make sure it agrees with the loader code.

@erezsh
Copy link
Member

erezsh commented Jan 29, 2024

Yes, load_grammar.py is the "ground truth", for better or worse.

@RossPatterson
Copy link

PR #1388 submitted for my observations above, plus several others I found.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Discuss new features or other changes
Projects
None yet
4 participants