[Haskell-cafe] Fwd: Haskell grammar ambiguity
evincarofautumn at gmail.com
Wed Jun 16 20:37:48 UTC 2021
Email fail, pardon the noise; original message below.
---------- Forwarded message ---------
From: Jon Purdy <evincarofautumn at gmail.com>
Date: Wed, Jun 16, 2021 at 1:35 PM
Subject: Re: [Haskell-cafe] Haskell grammar ambiguity
To: Sven Panne <svenpanne at gmail.com>
On Wed, Jun 16, 2021 at 12:49 AM Sven Panne <svenpanne at gmail.com> wrote:
> I consider ambiguous grammars a serious usability bug.
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!)
> The BlockArguments proposal introduced lots of additional ambiguities, and
> that's the reason why I'm still opposed to it.
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.
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.
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe