- EBNF-inspired grammar, with extra features (See: [Grammar Reference](grammar.md))
- Builds a parse-tree (AST) automagically based on the grammar
- Builds a parse-tree (AST) automagically based on the grammar
- Stand-alone parser generator - create a small independent parser to embed in your project.
- Automatic line & column tracking
- Automatic terminal collision resolution
@@ -39,16 +39,17 @@ Lark extends the traditional YACC-based architecture with a *contextual lexer*,
The contextual lexer communicates with the parser, and uses the parser's lookahead prediction to narrow its choice of tokens. So at each point, the lexer only matches the subgroup of terminals that are legal at that parser state, instead of all of the terminals. It’s surprisingly effective at resolving common terminal collisions, and allows to parse languages that LALR(1) was previously incapable of parsing.
This is an improvement to LALR(1) that is unique to Lark.
This is an improvement to LALR(1) that is unique to Lark.
### CYK Parser
A [CYK parser](https://www.wikiwand.com/en/CYK_algorithm) can parse any context-free grammar at O(n^3*|G|).
A [CYK parser](https://www.wikiwand.com/en/CYK_algorithm) can parse any context-free grammar at O(n^3*|G|).
Its too slow to be practical for simple grammars, but it offers good performance for highly ambiguous grammars.
# Other features
# Extra features
- Import rules and tokens from other Lark grammars, for code reuse and modularity.
- Import grammars from Nearley.js
### Experimental features
@@ -59,4 +60,3 @@ Its too slow to be practical for simple grammars, but it offers good performance
- Grammar composition
- LALR(k) parser
- Full regexp-collision support using NFAs
- Automatically produce syntax-highlighters for grammars, for popular IDEs
All occurrences of the terminal will be ignored, and won't be part of the parse.
Using the `%ignore` directive results in a cleaner grammar.
It's especially important for the LALR(1) algorithm, because adding whitespace (or comments, or other extranous elements) explicitly in the grammar, harms its predictive abilities, which are based on a lookahead of 1.
**Syntax:**
```html
%ignore <TERMINAL>
@@ -122,9 +126,9 @@ COMMENT: "#" /[^\n]/*
```
### %import
Allows to import terminals from lark grammars.
Allows to import terminals and rules from lark grammars.
Future versions will allow to import rules and macros.
When importing rules, all their dependencies will be imported into a namespace, to avoid collisions. It's not possible to override their dependencies (e.g. like you would when inheriting a class).
@@ -10,7 +10,7 @@ This is the recommended process for working with Lark:
3. Try your grammar in Lark against each input sample. Make sure the resulting parse-trees make sense.
4. Use Lark's grammar features to [[shape the tree|Tree Construction]]: Get rid of superfluous rules by inlining them, and use aliases when specific cases need clarification.
4. Use Lark's grammar features to [[shape the tree|Tree Construction]]: Get rid of superfluous rules by inlining them, and use aliases when specific cases need clarification.
- You can perform steps 1-4 repeatedly, gradually growing your grammar to include more sentences.
@@ -18,39 +18,15 @@ This is the recommended process for working with Lark:
Of course, some specific use-cases may deviate from this process. Feel free to suggest these cases, and I'll add them to this page.
## Basic API Usage
## Getting started
For common use, you only need to know 3 classes: Lark, Tree, Transformer ([[Classes Reference]])
Browse the [Examples](https://github.com/lark-parser/lark/tree/master/examples) to find a template that suits your purposes.
Here is some mock usage of them. You can see a real example in the [[examples]]
Read the tutorials to get a better understanding of how everything works. (links in the [main page](/))
```python
from lark import Lark, Transformer
grammar = """start: rules and more rules
rule1: other rules AND TOKENS
| rule1 "+" rule2 -> add
| some value [maybe]
rule2: rule1 "-" (rule2 | "whatever")*
TOKEN1: "a literal"
TOKEN2: TOKEN1 "and literals"
"""
parser = Lark(grammar)
Use the [Cheatsheet (PDF)](lark_cheatsheet.pdf) for quick reference.
tree = parser.parse("some input string")
class MyTransformer(Transformer):
def rule1(self, matches):
return matches[0] + matches[1]
# I don't have to implement rule2 if I don't feel like it!
new_tree = MyTransformer().transform(tree)
```
Use the reference pages for more in-depth explanations. (links in the [main page](/)]
@@ -27,7 +27,7 @@ In accordance with these principles, I arrived at the following design choices:
### 1. Separation of code and grammar
Grammars are the de-facto reference for your language, and for the structure of your parse-tree. For any non-trivial language, the conflation of code and grammar always turns out convoluted and difficult to read.
Grammars are the de-facto reference for your language, and for the structure of your parse-tree. For any non-trivial language, the conflation of code and grammar always turns out convoluted and difficult to read.
The grammars in Lark are EBNF-inspired, so they are especially easy to read & work with.
@@ -45,13 +45,13 @@ And anyway, every parse-tree can be replayed as a state-machine, so there is no
See this answer in more detail [here](https://github.com/erezsh/lark/issues/4).
You can skip the building the tree for LALR(1), by providing Lark with a transformer (see the [JSON example](https://github.com/erezsh/lark/blob/master/examples/json_parser.py)).
To improve performance, you can skip building the tree for LALR(1), by providing Lark with a transformer (see the [JSON example](https://github.com/erezsh/lark/blob/master/examples/json_parser.py)).
### 3. Earley is the default
The Earley algorithm can accept *any* context-free grammar you throw at it (i.e. any grammar you can write in EBNF, it can parse). That makes it extremely useful for beginners, who are not aware of the strange and arbitrary restrictions that LALR(1) places on its grammars.
As the users grow to understand the structure of their grammar, the scope of their target language and their performance requirements, they may choose to switch over to LALR(1) to gain a huge performance boost, possibly at the cost of some language features.
As the users grow to understand the structure of their grammar, the scope of their target language and their performance requirements, they may choose to switch over to LALR(1) to gain a huge performance boost, possibly at the cost of some language features.
In short, "Premature optimization is the root of all evil."
@@ -60,4 +60,4 @@ In short, "Premature optimization is the root of all evil."
- Automatically resolve terminal collisions whenever possible
- Automatically keep track of line & column numbers