<div dir="ltr"><div dir="ltr">Am Di., 20. Apr. 2021 um 12:57 Uhr schrieb Benjamin Redelings <<a href="mailto:benjamin.redelings@gmail.com">benjamin.redelings@gmail.com</a>>:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">[...] I'm still curious about why the GHC parser does not use a grammar that <br>
is closer to the language grammar.  Is this mostly for historical <br>
reasons?  Are GLR parsers too slow?  I don't know what fraction of the <br>
compilation time is spent in parsing, but would suspect it is not that much.<br></blockquote><div><br></div><div>I think there are various aspects:</div><div>   * Tool support (i.e. historic reasons): Happy is a LALR parser generator.</div><div>   * Quality of error reporting: I don't have a clue how good GLR parsers are in this area. Often more powerful parsing methods have horrible reporting, at least that's my impression.</div><div>   * Does the GLR parser generator detect ambiguities and report them to the grammar writer? To me, ambiguities (like the shift/reduce & reduce/reduce conflicts in LALR parsing) are a big red flag and a sign of a questionable language/grammar: Even if the generator/parser is able to figure things out correctly, humans have a much harder time.</div><div><br></div><div>Cheers,</div><div>   S.</div></div></div>