Content deleted Content added
m Dating maintenance tags: {{Citation needed}} |
m Replaced 1 bare URLs by {{Cite web}}; Replaced "Archived copy" by actual titles |
||
(22 intermediate revisions by 15 users not shown) | |||
Line 1:
{{Short description|Computer mechanic}}
{{more citations needed|date=November 2024}}
In [[computer science]], a '''Simple LR''' or '''SLR parser''' is a type of [[LR parser]] with small [[LR parser#Constructing LR(0) parsing tables|parse table]]s and a relatively simple parser generator algorithm. As with other types of LR(1) parser, an SLR parser is quite efficient at finding the single correct [[bottom-up parsing|bottom-up parse]] in a single left-to-right scan over the input stream, without guesswork or backtracking. The parser is mechanically generated from a formal grammar for the language.
SLR and the more
SLR and LALR were both developed by [[Frank DeRemer]] as the first practical uses of [[Donald Knuth]]'s LR parser theory.<ref>{{
== Lookahead sets ==
To understand the differences between SLR and LALR, it is important to understand their many similarities and how they both make shift-reduce decisions. (See
The one difference between SLR and LALR is how their generators calculate the
SLR generators calculate that lookahead by an easy approximation method based directly on the grammar, ignoring the details of individual parser states and transitions. This ignores the particular context of the current parser state. If some nonterminal symbol ''S'' is used in several places in the grammar, SLR treats those places in the same single way rather than handling them individually.
LALR generators calculate lookahead sets by a more precise method based on exploring the graph of parser states and their transitions. This method considers the particular context of the current parser state. It customizes the handling of each grammar occurrence of some nonterminal S. See article [[LALR parser]] for further details of this calculation. The lookahead sets calculated by LALR generators are a subset of (and hence better than) the approximate sets calculated by SLR generators. If a grammar has table conflicts when using SLR follow sets, but is conflict-free when using LALR follow sets, it is called a LALR grammar. {{citation needed|date=November 2024}}
== Example ==
Line 24 ⟶ 25:
Constructing the action and goto table as is done for LR(0) parsers would give the following item sets and tables:
: S → • E
: + E → • 1 E
: + E → • 1
: E → 1 • E
: E → 1 •
Line 35 ⟶ 36:
: + E → • 1
: S → E •
: E → 1 E •
Line 45 ⟶ 46:
{| class="wikitable"
|- align="center"
|- align="center"
!1||$||E
|- align="center"
!0
|- align="center"
!1
|- align="center"
!2
|- align="center"
!3
|}
Line 61 ⟶ 67:
{| class="wikitable"
|- align="center"
|S||E||1 |- align="center"
|$||$||1,$ |}
A reduce only needs to be added to a particular action column if that action is in the follow set associated with that reduce. This algorithm describes whether a reduce action must be added to an action column:
function mustBeAdded(reduceAction, action) {
ruleNumber = reduceAction.value;
ruleSymbol = rules[ruleNumber].leftHandSide;
return (action in followSet(ruleSymbol))
}
for example, {{code|mustBeAdded(r2, "1")}} is false, because the left hand side of rule 2 is "E", and 1 is not in E's follow set.
Contrariwise, {{code|mustBeAdded(r2, "$")}} is true, because "$" is in E's follow set.
By using mustBeAdded on each reduce action in the action table, the result is a conflict-free action table:
Line 81 ⟶ 89:
{| class="wikitable"
|- align="center"
|- align="center"
!1||$||E
|- align="center"
!0
|- align="center"
!1
|- align="center"
!2
|- align="center"
!3
|}
Line 99 ⟶ 112:
* [[LALR parser]]
* [[SLR grammar]]
==References==
{{reflist}}
{{Parsers}}
[[Category:Parsing algorithms]]
|