[Haskell-cafe] Haskell grammar ambiguity
lysxia at gmail.com
Wed Jun 16 13:07:40 UTC 2021
On 6/16/2021 5:00 AM, Tom Ellis wrote:
> Entirely agreed. The additional difficulty in parsing means that
> BlockArguments provides *negative* value to me, even if I don't enable
Ouch, that error message is terrible.
But isn't that an argument against BlockArguments more than against
ambiguity? By that I mean that the current ambiguities for function
applications were already present in a similar form for infix
expressions in Haskell2010 (replacing a space with an operator).
In a parallel world, the Haskell2010 grammar could be unambiguous,
BlockArguments would keep the extended grammar unambiguous. But since
the intended meaning is the same, GHC would be the same as in this
world, and you would still be having the same issues with BlockArguments.
> On Wed, Jun 16, 2021 at 09:48:06AM +0200, Sven Panne wrote:
>> Am Mi., 16. Juni 2021 um 08:47 Uhr schrieb Li-yao Xia <lysxia at gmail.com>:
>>> [...] - An ambiguous grammar may be more readable (since there are
>>> more choices available), especially if you care more about the AST than
>>> the concrete syntax. [...]
>> IMHO it is exactly the other way around: I consider ambiguous
>> grammars a serious usability bug. [...] The BlockArguments proposal
>> introduced lots of additional ambiguities, and that's the reason why
>> I'm still opposed to it.
>> In general, I consider it a very bad idea to give more and more strings a
>> meaning as a program: Some redundancy, like keywords and/or punctuation, is
>> highly useful as a human reader. Remember the old saying "A good language
>> should not make it easy to write correct programs, it should make it hard
>> to write incorrect ones", and BlockArguments was IMHO a step into the wrong
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> Only members subscribed via the mailman list are allowed to post.
More information about the Haskell-Cafe