[ghc-steering-committee] A plea for BlockArguments

[Simon Marlow]

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 <eric at seidel.io> wrote:

> 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
> >
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201205/5cefa3c5/attachment.html>