I'm in the same position as Eric: it seems plausible but I haven't used it
- it was added in 8.6.1, and doesn't even exist in the version of GHC we
are using at FB! So I haven't developed a sense for how well it works in
practice. Perhaps we should punt on this until GHC2022 given that it's so
new, though?
Cheers
Simon
On Sat, 5 Dec 2020 at 00:57, Eric Seidel
I really like the idea of BlockArguments, but I haven't had enough of an opportunity to experiment with it to see how it feels in practice, so I marked it as "maybe". I'd be happy to hear from people who do have the experience though.
On Fri, Dec 4, 2020, at 13:34, Richard Eisenberg wrote:
I almost sent out a plea for BlockArguments, but decided not to overplea. I agree fully with Iavor here.
BlockArguments is a *simplification* over the status quo. Look at the grammars in
https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0090-bl.... We see that the new grammar (the second block) effectively has one fewer nonterminal (lexp becomes redundant). Consequently, users no longer have to remember which forms belong in which nonterminal.
One of the arguments against BlockArguments was that the change was so trivial, likely saving fewer characters than writing the extension name would take. But having it on my default makes it much more useful. Indeed, I would advocate (at some appropriate time in the future) for deprecating -XNoBlockArguments.
All that said, I don't use BlockArguments myself, because I find the parentheses a tiny bit helpful. But nothing about this extension means I can't keep doing what I've been doing.
NB: There is a big difference between BlockArguments and the weird precedence around record-update. In `f r { field = new_val }`, we learn that there is a record-update only *after* reading `r`, and so we humans have to go back and re-parse. In the case of the re-associated constructs in -XBlockArguments, there is a keyword herald (counting \ as a keyword), and so no re-parsing is necessary.
Richard
On Dec 4, 2020, at 11:26 AM, Spiwack, Arnaud
wrote:
The baseline question is: what is the consequence for someone who
doesn't use the extension. I've never turned it on, I have no idea of the consequences. It's been around for some two years already (8.6). Is it commonly used?
On Fri, Dec 4, 2020 at 5:23 PM Iavor Diatchki <
iavor.diatchki@gmail.com> wrote:
While we are pleading for things, I'd really like to have BlockArguments on by default, as I use them all the time, and I really don't think that adding the extension to a module adds much information.
I realize that this is mostly a stylistic issue, and some programmers are going to prefer to write explicit parens, which is perfectly fine and in now way incompatible with BlockArguments.
Personally I like the extension because, while it takes a bit of getting used to, for me it leads to less syntactic noise in the code, which makes it easier to read and manipulate code. _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee