diff --git a/docs/classes.md b/docs/classes.md index 9943fd4..f77d7b8 100644 --- a/docs/classes.md +++ b/docs/classes.md @@ -96,7 +96,7 @@ Trees can be hashed and compared. Transformers & Visitors provide a convenient interface to process the parse-trees that Lark returns. -They are used by inheriting from the correct class (visitor or transformer), and implementing methods corresponding to the rule you wish to process. Each methods accepts the children as an argument. That can be modified using the `v-args` decorator, which allows to inline the arguments (akin to `*args`), or add the tree `meta` property as an argument. +They are used by inheriting from the correct class (visitor or transformer), and implementing methods corresponding to the rule you wish to process. Each methods accepts the children as an argument. That can be modified using the `v_args` decorator, which allows to inline the arguments (akin to `*args`), or add the tree `meta` property as an argument. See: https://github.com/lark-parser/lark/blob/master/lark/visitors.py diff --git a/docs/grammar.md b/docs/grammar.md index 228c8b7..8a8913b 100644 --- a/docs/grammar.md +++ b/docs/grammar.md @@ -179,7 +179,7 @@ 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. +It's especially important for the LALR(1) algorithm, because adding whitespace (or comments, or other extraneous elements) explicitly in the grammar, harms its predictive abilities, which are based on a lookahead of 1. **Syntax:** ```html diff --git a/docs/how_to_develop.md b/docs/how_to_develop.md index d69a1e3..b161e0c 100644 --- a/docs/how_to_develop.md +++ b/docs/how_to_develop.md @@ -7,7 +7,7 @@ There are many ways you can help the project: * Write new grammars for Lark's library * Write a blog post introducing Lark to your audience * Port Lark to another language -* Help me with code developemnt +* Help me with code development If you're interested in taking one of these on, let me know and I will provide more details and assist you in the process. @@ -60,4 +60,4 @@ Another way to run the tests is using setup.py: ```bash python setup.py test -``` \ No newline at end of file +``` diff --git a/docs/parsers.md b/docs/parsers.md index fb7c997..c487238 100644 --- a/docs/parsers.md +++ b/docs/parsers.md @@ -5,9 +5,9 @@ Lark implements the following parsing algorithms: Earley, LALR(1), and CYK An [Earley Parser](https://www.wikiwand.com/en/Earley_parser) is a chart parser capable of parsing any context-free grammar at O(n^3), and O(n^2) when the grammar is unambiguous. It can parse most LR grammars at O(n). Most programming languages are LR, and can be parsed at a linear time. -Lark's Earley implementation runs on top of a skipping chart parser, which allows it to use regular expressions, instead of matching characters one-by-one. This is a huge improvement to Earley that is unique to Lark. This feature is used by default, but can also be requested explicitely using `lexer='dynamic'`. +Lark's Earley implementation runs on top of a skipping chart parser, which allows it to use regular expressions, instead of matching characters one-by-one. This is a huge improvement to Earley that is unique to Lark. This feature is used by default, but can also be requested explicitly using `lexer='dynamic'`. -It's possible to bypass the dynamic lexing, and use the regular Earley parser with a traditional lexer, that tokenizes as an independant first step. Doing so will provide a speed benefit, but will tokenize without using Earley's ambiguity-resolution ability. So choose this only if you know why! Activate with `lexer='standard'` +It's possible to bypass the dynamic lexing, and use the regular Earley parser with a traditional lexer, that tokenizes as an independent first step. Doing so will provide a speed benefit, but will tokenize without using Earley's ambiguity-resolution ability. So choose this only if you know why! Activate with `lexer='standard'` **SPPF & Ambiguity resolution** @@ -21,7 +21,7 @@ Lark provides the following options to combat ambiguity: 1) Lark will choose the best derivation for you (default). Users can choose between different disambiguation strategies, and can prioritize (or demote) individual rules over others, using the rule-priority syntax. -2) Users may choose to recieve the set of all possible parse-trees (using ambiguity='explicit'), and choose the best derivation themselves. While simple and flexible, it comes at the cost of space and performance, and so it isn't recommended for highly ambiguous grammars, or very long inputs. +2) Users may choose to receive the set of all possible parse-trees (using ambiguity='explicit'), and choose the best derivation themselves. While simple and flexible, it comes at the cost of space and performance, and so it isn't recommended for highly ambiguous grammars, or very long inputs. 3) As an advanced feature, users may use specialized visitors to iterate the SPPF themselves. Future versions of Lark intend to improve and simplify this interface.