[ghc-steering-committee] A plea for BlockArguments

[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-block-arguments.rst#proposed-change-specification. 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 <arnaud.spiwack at tweag.io> 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 at 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 at haskell.org
> >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>