Computer Science Stack Exchange is a question and answer site for students, researchers and practitioners of computer science. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I try to teach myself the usage of bison. The manpage bison(1) says about bison:

Generate a deterministic LR or generalized LR (GLR) parser employing LALR(1), IELR(1), or canonical LR(1) parser tables.

What is an IELR-parser? All relevant articles I found on the world wide web are paywalled.

share|cite|improve this question
Including ? – reinierpost Sep 7 '12 at 17:56
@reinierpost I feel so stupid right now. Why didn't I find this? – FUZxxl Sep 7 '12 at 18:59
I don't know - Google does personalize results ... – reinierpost Sep 10 '12 at 7:43
@reinierpost, would you like to answer this question by quoting your link, so as to clean this question up? – Merbs Nov 27 '12 at 7:26
Hmmm ... if that's all it takes, OK. – reinierpost Dec 5 '12 at 10:39
up vote 5 down vote accepted

An article that claims to introduce it: IELR(1): Practical LR(1) Parser Tables for Non-LR(1) Grammars with Conflict Resolution by Joel E. Denny and Brian A. Malloy, Clemson University, is freely available from Malloy's site.

What they are worth is something I can't answer. (Personally I don't understand the need for such crippled CFG parsing - why limit your expressive power when you can just use GLR? What does make sense to me is something like TAG or PEG (they seem natural and add expressive power) or tree grammars (for languages such as XML in which recognizing parse trees is trivial by design).)

share|cite|improve this answer
While I do agree on principle regarding technology, the problem is often that traditional deterministic parsing has better, more complete implementations. Another issue is that General CF parsing is more powerful, but GLR may not be the best version of it. – babou Dec 10 '14 at 12:27
The main reason for why people have developed hobbled CFG parsers is that a GLR parser does not necessarily run in linear time—this is a huge problem for many applications. An IELR parser can guarantee linear runtime and more. – FUZxxl Oct 1 '15 at 18:58
I don't understand why it would be a problem. – reinierpost Oct 1 '15 at 20:37
@reinierpost It's linear time vs. worst-case-$O(n^4)$ (GLR) or $O(n^3)$ (GLL). For e.g. compiling large source files, this can add up lots of time. Furthermore, the attitude of preferring expressiveness over constraint without support neglects the time sacrifice involved. Technically we could use the super-expressive sLMG and/or PMCFG formalisms but then we'd be dealing with up to $lim_{x\rightarrow\infty} O(n^x)$. That might be an absurd example, but the motivation is always time. Humans don't live forever and have a lot to do. Wasting their time is generally bad. – user Oct 10 '15 at 9:24
I would like to note that "Personally I don't understand the need for such crippled CFG parsing - why limit your expressive power when you can just use GLR?" is rather misguided in this context. IELR(1) is used to generate more efficient LR(1) parser tables, which allows for more efficient GLR parsers. – orlp Jan 1 at 9:36

Your Answer


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

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