
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 it:
http://h2.jaguarpaw.co.uk/posts/unhelpful-ghc-error-messages/
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
: [...] - An ambiguous grammar may be more readable (since there are strictly 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 direction.
Tom _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.