Take the 2-minute tour ×
Computer Science Stack Exchange is a question and answer site for students, researchers and practitioners of computer science. It's 100% free, no registration required.

In compiler design, why should left recursion be eliminated in grammars? I am reading that it is because it can cause an infinite recursion, but is it not true for a right recursive grammar as well?

share|improve this question
Typically, compilers use top-down parsing. If you have left-recursion, then the parser goes into an infinite recursion. However, in right-recursion, the parser can see the prefix of the string that it has so far. Thus, it can check whether the derivation went "too far". You can, of course, swap the roles and interpret expressions from the right, making right-recursion bad, and left-recursion fine. –  Shaull Feb 20 '13 at 10:20
Left recursion is bad because in the old days when computers had 16 KB of RAM the most commonly used parser generator could not cope with it. –  Andrej Bauer Feb 20 '13 at 13:38
add comment

migrated from cstheory.stackexchange.com Feb 20 '13 at 10:22

This question came from our site for theoretical computer scientists and researchers in related fields.

2 Answers

Left recursive grammars are not necessarily a bad thing. These grammars are easily parsed using a stack to keep track of the already parsed phrases, as it is the case in LR parser.

Recall that a left recursive rule of a CF grammar $G = (V,\Sigma,R,S)$ is of the form:

$\alpha \rightarrow \alpha \beta$

with $\alpha$ an element of $V$ and $\beta$ an element of $V \cup \Sigma$. (See the complete formal definition for the tuple $(V,\Sigma,R,S)$ there).

Usually, $\beta$ is actually a sequence of terminals and non terminals, and there is an other rule for $\alpha$ where $\alpha$ does not appear in the right hand side.

Whenever a new terminal is being received by the grammar parser (from the lexer), this terminal is pushed atop the stack: this operation is called a shift.

Each time the right hand side of a rule is matched by a group of consecutive elements at the top of the stack, this group is replaced by a single element representing the phrase newly matched. This replacement is called a reduction.

With right recursive grammars, the stack may grow indefinitely until a reduction occurs, thus limiting rather dramatically the parsing possibilities. However, left recursive ones will let the compiler generate reductions earlier (in fact, as soon as possible). See the wikipedia entry for more information.

share|improve this answer
It would help if you defined your variables. –  Andrew S Mar 29 at 19:58
add comment

Consider this rule:

example : 'a' | thingie 'b' ;

Now consider a LL parser trying to match a non-matching string like 'b' to this rule. Since 'a' doesn't match, it'll try to match example 'b'. But in order to do so, it has to match example...which is what it was trying to do in the first place. It could get stuck trying forever to see whether it can match, because it's always trying to match the same stream of tokens to the same rule.

In order to prevent that, you'd either have to parse from the right (which is quite uncommon, as far as i've seen, and would make right recursion the problem instead), artificially limit the amount of nesting allowed, or match a token before the recursion starts so there's always a base case (namely, where all the tokens have been consumed and there's still no complete match). Since a right-recursive rule already does the third, it doesn't have the same problem.

share|improve this answer
You are sort of blindly assuming that parsing is necessarily naive top-down parsing. –  reinierpost Feb 21 '13 at 13:17
I'm highlighting a pitfall of a rather common method of parsing -- a problem that can easily be avoided. It's certainly possible to handle left-recursion, but retaining it creates an almost-always-unnecessary limitation on the type of parser that can use it. –  cHao Feb 21 '13 at 19:10
Yes, that's a more constructive and useful way of putting it. –  reinierpost Feb 22 '13 at 19:43
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.