<div dir="ltr">Email fail, pardon the noise; original message below.<br><div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">---------- Forwarded message ---------<br>From: <b class="gmail_sendername" dir="auto">Jon Purdy</b> <span dir="auto"><<a href="mailto:evincarofautumn@gmail.com">evincarofautumn@gmail.com</a>></span><br>Date: Wed, Jun 16, 2021 at 1:35 PM<br>Subject: Re: [Haskell-cafe] Haskell grammar ambiguity<br>To: Sven Panne <<a href="mailto:svenpanne@gmail.com">svenpanne@gmail.com</a>><br></div><br><br><div dir="ltr"><div dir="ltr">On Wed, Jun 16, 2021 at 12:49 AM Sven Panne <<a href="mailto:svenpanne@gmail.com" target="_blank">svenpanne@gmail.com</a>> wrote:<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"><div dir="ltr"><div class="gmail_quote"><div>I consider ambiguous grammars a serious usability bug.</div></div></div></blockquote><div><br></div><div>I agree. I always make a point of telling ‘%expect 0’ to Happy. (“More often than not the grammar you write will have conflicts”? Excuse you!)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>The BlockArguments proposal introduced lots of additional ambiguities, and that's the reason why I'm still opposed to it.</div></div></div></blockquote><div><br></div><div>I consider BlockArguments a fix for a bug in the Haskell grammar, namely, a redundant production, requiring an unnecessary operator, which causes confusion for some people coming from other languages. In being fixed, however, it exposed other serious grammar issues. So I’d be strongly in favour of fixing those unclear/ambiguous parses by further (incremental) simplification of the grammar.</div><div><br></div><div>It would be very nice if the extent of lambda/if/&c. were unambiguous, so I think this idea is a step in the right direction. I would also be very pleased if the layout rule were reformulated as a simpler desugaring step, from a token stream annotated with source locations to such a stream with explicit braces and semicolons inserted, rather than being defined in terms of parse errors and papering over edge cases.</div><div><br></div><div>My ideal would be a simple formal grammar (LALR, PEG, or even operator-precedence) which is machine-validated as unambiguous, with an implementation written by hand to produce nice contextual error messages, which is typed to prove that it accepts the same language as the formal grammar.<br></div></div></div>
</div></div></div></div>