Why are ambiguous grammars usually a bad idea? Why are languages usually defined and implemented with ambiguous grammars?

Roger L Costello <costello@mitre.org>
Thu, 16 Dec 2021 13:12:39 +0000

          From comp.compilers

Related articles
| List of all articles for this month |
From: Roger L Costello <costello@mitre.org>
Newsgroups: comp.compilers
Date: Thu, 16 Dec 2021 13:12:39 +0000
Organization: Compilers Central
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="8261"; mail-complaints-to="abuse@iecc.com"
Keywords: design, question, comment
Posted-Date: 26 Dec 2021 22:00:48 EST
Accept-Language: en-US
Content-Language: en-US

Hello Compiler Experts!


I am reading the (excellent) book "flex & bison" by John Levine. Chapter 7
talks about conflicts in grammars: shift/reduce and reduce/reduce conflicts.


At the end of the chapter are a few exercises/questions. I'd like to check
with you on whether my answers to the questions are accurate and complete.


Question: Beyond the fact that bison doesn't like them, why are ambiguous
grammars usually bad?


My answer: Ambiguous grammars make it hard for users of the grammar to write
correct instances of the grammar. Stated another way, ambiguous grammars make
it easy to introduce errors into instances of the grammar.


Question: Opine about why languages are usually defined and implemented with
ambiguous grammars.


My answer: Writing a grammar that completely avoids ambiguities might result
in a grammar that is nightmarishly complex. It is easier/better to create a
simple grammar and then add rules/descriptions which explain and resolve the
ambiguities.


Are my answers correct? Are they complete?


/Roger
[Sounds good to me. Also keep in mind that the LALR parser cannot parse all unambiguous
grammars, only the ones that fit the LALR model, so sometimes as you say it's easier
to handle some of the structure outside the grammar. -John]


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.