Document rule precedence + slight clarification for error recovery

This commit is contained in:
Robin Jadoul 2017-01-30 20:57:18 +01:00
parent 25e346b8cd
commit 9136756c04
1 changed files with 3 additions and 1 deletions

View File

@ -104,7 +104,7 @@ Furthermore, Parsodus uses a couple of key-value associations, including
- start: a variable to use as the start symbol - start: a variable to use as the start symbol
- grammar: a list of rules (see below) - grammar: a list of rules (see below)
A grammar rule is a variable followed by `::=` followed by a `|`-separated list of rule tails ended with a semicolon. A rule tail is a list of variables and terminals followed by an optional rule name of the form `[name]`. A grammar rule is a variable followed by `::=` followed by a `|`-separated list of rule tails ended with a semicolon. A rule tail is a list of variables and terminals followed by an optional rule name of the form `[name]`. These annotations can additionally contain a specific precedence for this rule (a common example for this is the unary minus in mathematical expressions) in the form of a precedence specifier (`left`, `right` or `nonassoc`) followed by a non-negative integer. This integer specifies the precedence level for that rule (higher means higher precedence). Otherwise, the precedence for a rule is determined by the precedence of its last terminal. The lowest precedence in the *precedence* section of the file has precedence level 0.
parser: lalr(1) parser: lalr(1)
terminals: terminals:
@ -130,6 +130,8 @@ In general, there should be some way to run the parser, along with user defined
If you provide a rule with `<error>` somewhere inside the body, this can be used to recover from errors. The generated parser will discard states until it encounters somewhere it can use such a rule. Afterwards, it will start discarding tokens until it can proceed in parsing. If it's impossible to recover from the error (cannot find a recovery rule or cannot find a synchronizing token before EOF), there will generally be an error (depending on the backend). Usually, some sort of reporting mechanism should also be in place by the generated parser. If you provide a rule with `<error>` somewhere inside the body, this can be used to recover from errors. The generated parser will discard states until it encounters somewhere it can use such a rule. Afterwards, it will start discarding tokens until it can proceed in parsing. If it's impossible to recover from the error (cannot find a recovery rule or cannot find a synchronizing token before EOF), there will generally be an error (depending on the backend). Usually, some sort of reporting mechanism should also be in place by the generated parser.
`<error>` should never appear as the head of a grammar rule.
### Bash completion ### Bash completion
A file that provides bash completion is also provided for your convenience, to use it, do: A file that provides bash completion is also provided for your convenience, to use it, do: