I have a problem with this exercise:

Let G be the following ambiguous grammar for the λ-calculus:

E → v | λv.E | EE | (E)

where E is the single non-terminal symbol, λv.E represents abstraction w.r.t. the variable v in E, and EE represents application.

  1. Define an LL(1) grammar G′ such that L(G′) = L(G) and the ambiguity of G is resolved by imposing the following usual conventions:
    1. abstraction is right associative;
    2. application is left associative;
    3. application has higher priority than abstraction.
  2. Show the LL(1) parsing table for G′ and the parse tree obtained when parsing the string λv1. λv2. v1v2v1.

I eliminated ambiguity setting precedence and association, obtaining this grammar:

E -> EF | F
F -> λv.G | G
G -> (E) | v

which is not LL(1), since the production E -> EF is left recursive. However, eliminating left recursion from that production I obtain:

E -> FE¹
E¹-> FE¹ | ɛ
F -> λv.G | G
G -> (E) | v

that does not comply with requirement 1.2.

I looked for a solution on the Internet, but it seems like it is not possible to eliminate left-recursion preserving left associativity.

However, this exercise appeared on the compilers exam some years ago, so there must be a correct answer.

Thank you for your help.


2 Answers 2


Compatibility of left associativity and LL(1) parsing

You just hit one of the major inconsistencies in the use of context-free (CF) syntax. People want to choose grammars so that the parse-tree will reflect the intended structure of the sentence, close to its semantics, especially in the case of non associative operators, such as application. This was pretty much the original intent of CF grammars in linguistics. But at the same time they are constraining themselves to parsing technology that will tolerate only some types of grammars.

Indeed, if the parse-tree is to reflect the left associativity of an operator, then the grammar is necessarily left-recursive, since the top application node in the parse-tree is necessarily adding the rightmost term of non-parethesized successive applications.. So LL parsing is out of the question. You are right.

There are two ways out of this. One is not to rely on the parser to give the rigth "parse-tree" to be used for later stages of processing (such as reducing the lambda expression, here). This lead to the concept of Abstract Syntax Trees (AST) that can be built from the parse-tree, but with a different structure.

The other solution is to use more general parsing Techniques that will accept any CF grammar, and parse in accordance with it. General CF parsers is a well developed technology (and I do not cease to wonder why LL remains so popular).

I have no idea what could be considered a proper answer to these contradicting requirements.

What I would do is show they are contradicting requirements. Give a first grammar that meets the associativity and priority constraints, then transform the grammar into and LL(1) grammar for the parsing.

The fact that something appeared in a journal or on an exam is not a total garantee that it is correct. And I might be wrong too ... but I did some checking, in addition to my own knowledge of the issue.

About this specific example

This being said, the first grammar you are suggesting does not seem quite correct. It does not have a way of producing λu.λv.v .

One trick to know is to start with operators (here abstraction or application) with the lowest priority (abstraction). It is the same for arithmetic expressions.

  • $\begingroup$ Thank you very much for your detailed comment. You're right, I did an error with the first grammar, thank you for this too. I'll ask the professor then. $\endgroup$ Commented May 29, 2015 at 12:55
  • $\begingroup$ I may add to the answer, with a small note on grammar design for dummies (me too), if you are interested. Also, tell us what your professor says on this. $\endgroup$
    – babou
    Commented May 29, 2015 at 13:20
  • $\begingroup$ I'll update the thread when the professor answers this question. Anyway, feel free to add more information if that's not a problem for you, of course I'd appreciate that a lot. Thank you again for your help $\endgroup$ Commented May 29, 2015 at 13:29
  • $\begingroup$ @MarcoDallaG Came across this when working on Pierce's TAPL. Did your professor happen to say anything different from this answer? :) $\endgroup$
    – lcn
    Commented Jul 21, 2018 at 9:01

My attempt:

E  -> A | λv.E
A  -> FA'
A' -> A | ɛ
F  -> (E) | v

This grammar is LL(1) and should respect the required properties.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.