<div dir="ltr"><div>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?</div><div><br></div><div>Cheers</div><div>Simon<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 5 Dec 2020 at 00:57, Eric Seidel <<a href="mailto:eric@seidel.io" target="_blank">eric@seidel.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.<br>
<br>
On Fri, Dec 4, 2020, at 13:34, Richard Eisenberg wrote:<br>
> I almost sent out a plea for BlockArguments, but decided not to <br>
> overplea. I agree fully with Iavor here.<br>
> <br>
> BlockArguments is a *simplification* over the status quo. Look at the <br>
> grammars in <br>
> <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0090-block-arguments.rst#proposed-change-specification" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0090-block-arguments.rst#proposed-change-specification</a>. 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.<br>
> <br>
> One of the arguments against BlockArguments was that the change was so <br>
> trivial, likely saving fewer characters than writing the extension name <br>
> would take. But having it on my default makes it much more useful. <br>
> Indeed, I would advocate (at some appropriate time in the future) for <br>
> deprecating -XNoBlockArguments.<br>
> <br>
> All that said, I don't use BlockArguments myself, because I find the <br>
> parentheses a tiny bit helpful. But nothing about this extension means <br>
> I can't keep doing what I've been doing.<br>
> <br>
> NB: There is a big difference between BlockArguments and the weird <br>
> precedence around record-update. In `f r { field = new_val }`, we learn <br>
> that there is a record-update only *after* reading `r`, and so we <br>
> humans have to go back and re-parse. In the case of the re-associated <br>
> constructs in -XBlockArguments, there is a keyword herald (counting \ <br>
> as a keyword), and so no re-parsing is necessary.<br>
> <br>
> Richard<br>
> <br>
> > On Dec 4, 2020, at 11:26 AM, Spiwack, Arnaud <<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.io</a>> wrote:<br>
> > <br>
> > 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?<br>
> > <br>
> > On Fri, Dec 4, 2020 at 5:23 PM Iavor Diatchki <<a href="mailto:iavor.diatchki@gmail.com" target="_blank">iavor.diatchki@gmail.com</a>> wrote:<br>
> >> 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.<br>
> >> <br>
> >> 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.<br>
> >> <br>
> >> 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.<br>
> >> _______________________________________________<br>
> >> ghc-steering-committee mailing list<br>
> >> <a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
> >> <a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
> > _______________________________________________<br>
> > ghc-steering-committee mailing list<br>
> > <a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
> > <a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
> <br>
> _______________________________________________<br>
> ghc-steering-committee mailing list<br>
> <a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
> <a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
><br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>