Re: Are compiler developers light-years ahead of other software development?

gah4 <gah4@u.washington.edu>
Fri, 21 Jan 2022 17:40:06 -0800 (PST)

          From comp.compilers

Related articles
| List of all articles for this month |
From: gah4 <gah4@u.washington.edu>
Newsgroups: comp.compilers
Date: Fri, 21 Jan 2022 17:40:06 -0800 (PST)
Organization: Compilers Central
References: 22-01-077 22-01-079
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="13350"; mail-complaints-to="abuse@iecc.com"
Keywords: parse, theory
Posted-Date: 21 Jan 2022 22:25:13 EST
In-Reply-To: 22-01-079

On Friday, January 21, 2022 at 2:30:42 PM UTC-8, Anton Ertl wrote:


(snip)


> This points to one reason why some people don't use these generators.
> You need to know quite a bit about the implementation technique behind
> it to understand what (for LR-based parser generators) a shift-reduce
> or reduce-reduce conflict means and how to fix that problem.


Interesting reason, as I know exactly how I learned about that.
(And not from compiler class, where I might have.)


In compiling a program, not actually changing it, the instructions warn
that it will get a shift-reduce conflict warning, and to ignore it.


There is a whole separate thread on ambiguous languages, which is
where these come from. In a language with an if-then-optional else
construct, and which can be nested, there is an ambiguity in which
if an else belongs to. In most such languages it goes to the nearest
(deepest nesting) if, and this is the default from the warning.


reduce-reduce results from an actual mistake in the language,
and does need to be fixed.


I believe the program was Kermit, but I am not so sure now the
details. I believe that it has an implementation language that
translates to C, using a lex/yacc parser. The Makefile does
it all for you, but you have to know to ignore the message.


Post a followup to this message

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