Question: how to prevent lark from recognizing parts of an identifier as a keyword?
See original GitHub issueHi, I have a little question.
parser = Lark('''
?start: value
| start "or" value -> or
?value: DIGIT -> digit
| ID -> id
DIGIT: /[1-9]\d*/
%import common.CNAME -> ID
%import common.WS
%ignore WS
''', parser='lalr')
print(parser.parse("1orfoo").pretty())
This code outputs the following:
or
digit 1
id foo
What can I do to make lakr recognize orfoo
as an identifier (thus throwing a syntax error in this case)?
Issue Analytics
- State:
- Created 3 years ago
- Comments:5 (2 by maintainers)
Top Results From Across the Web
How to prevent lark from recognizing parts of an identifier as a ...
Suppose I have the following grammar. I would expect lark to see it as the digit 1 followed by the identifier orfoo (thus...
Read more >Exception rules · Issue #434 · lark-parser/lark - GitHub
The obvious solution to solve this at the parser level, to me, is to disallow NAME or ID terminals from being keywords. Is...
Read more >Lark Documentation
Lark implements the Shared Packed Parse Forest data-structure for the Earley parser, in order to reduce the space and.
Read more >Difference between Keyword and Identifier - GeeksforGeeks
An identifier can be in upper case or lower case. A keyword contains only alphabetical characters.
Read more >Ubuntu Manpage: lark - Lark Documentation
In this tutorial we will write a JSON parser in Lark, and explore Lark's various features in the process. It has 5 parts....
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Sorry, this one slipped through the cracks.
That answer may work for this simple grammar, but it will severely limit your grammar going forward, if you plan to add more complex rules.
Maybe that’s fine for your use-case. But just fyi, there is another solution, which is to use a regex lookahead and ensure there’s no character after or:
_OR: /or(?!\w)/
This is a severe problem.