<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I almost sent out a plea for BlockArguments, but decided not to overplea. I agree fully with Iavor here.<div class=""><br class=""></div><div class="">BlockArguments is a *simplification* over the status quo. Look at the grammars in <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0090-block-arguments.rst#proposed-change-specification" class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Richard</div><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Dec 4, 2020, at 11:26 AM, Spiwack, Arnaud <<a href="mailto:arnaud.spiwack@tweag.io" class="">arnaud.spiwack@tweag.io</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">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 class=""></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Dec 4, 2020 at 5:23 PM Iavor Diatchki <<a href="mailto:iavor.diatchki@gmail.com" class="">iavor.diatchki@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class="">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.<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div></div>
_______________________________________________<br class="">
ghc-steering-committee mailing list<br class="">
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank" class="">ghc-steering-committee@haskell.org</a><br class="">
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank" class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br class="">
</blockquote></div>
_______________________________________________<br class="">ghc-steering-committee mailing list<br class=""><a href="mailto:ghc-steering-committee@haskell.org" class="">ghc-steering-committee@haskell.org</a><br class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<br class=""></div></blockquote></div><br class=""></div></body></html>