[ghc-steering-committee] Extra Commas (#87), Recommend: accept

Mon Aug 6 00:36:38 UTC 2018

Hi,

similar ambivalence here. If it were not for TupleSections, I’d be
clearly in favor. But both TupleSections and ExtraCommas would be
clearly marked in in the header of the file¹, and thus be signposted.

The proposal currently says “There is a potential interaction with
TupleSections”. Why potential? Is it, or is it not?

Also, Simon’s request for an explicit listing of all the BNF changes
has not happened yet. Chris, maybe request that first from the authors
(i.e. return this as “Revision needed”)?

I am not sure if the “let’s do this everywhere, but not with tuples” is
a good approach. Note that TupleSections is still only an extension,
and we _could_ decide that it is better to have uniformity in
ExtraCommas, at the expense of making it simply incompatible with
TupleSections. I am not sure about this, but I’d at least want to
discuss the option.

Although even ignoring TupleSections, extending ExtraCommas to tuples
raises the question of how (,) should parse – is it the pair
constructor, or the unit constructor with an extra comma.

So maybe _that_ incompatibility with Haskell98 is the real reason why
ExtraCommas just cannot work for tuples.

Cheers,
Joachim

Am Sonntag, den 05.08.2018, 10:47 -0400 schrieb Richard Eisenberg:
> I'm ambivalent on this one, seeing both sides of the argument. If I had to choose, I would lean toward "accept" based on the generally positive response the idea has seen.
> 
> Richard
> 
> > On Aug 4, 2018, at 4:18 PM, Eric Seidel <eric at seidel.io> wrote:
> > 
> > I agree with Chris, the ergonomic benefits to allowing a leading/trailing comma would be substantial. It would be nice if we had smart, structure-aware editors that made it easy to swap around sequence elements, but they never really caught on. Most people still use line-oriented editors, so I think we should support the more line-oriented editing flow that extra commas enable.
> > 
> > It's unfortunate that the extension would conflict with TupleSections, but I don't think that's sufficient reason to block it.
> > 
> > I'm in favor of accepting the proposal.
> > 
> > On Sat, Aug 4, 2018, at 16:08, Iavor Diatchki wrote:
> > > I find the "cleaner diffs" or "easier editing" motivations to be very weak,
> > > and I'd rather not have to explain why `[1,2,]` is a list, but `(1,2,)` is
> > > a function.
> > > 
> > > 
> > > 
> > > On Sat, Aug 4, 2018 at 9:31 PM Christopher Allen <cma at bitemyapp.com> wrote:
> > > 
> > > > Qualifying what I said toward the end, I don't think we should
> > > > encourage clutter either. Trailing commas is an ergonomic idea that is
> > > > already getting proved out by another language community.
> > > > 
> > > > On Sat, Aug 4, 2018 at 1:27 PM, Christopher Allen <cma at bitemyapp.com>
> > > > wrote:
> > > > > I've been using Rust which has terminal commas in the syntactic
> > > > > enumerations and it's, frankly, lovely. Less editing and easier
> > > > > copy/paste or use of macros when I am munging code. If it seems sloppy
> > > > > to you, it's probably because you aren't accustomed to it.
> > > > > 
> > > > > We have to remember that we work with code and not sentential English.
> > > > > In my view, mechanical ease should take priority over apparent
> > > > > naturalness. There have been many people who've objected that Haskell
> > > > > function application syntax is unnatural because they are accustomed
> > > > > to C-style f(arg, arg1) syntax.
> > > > > 
> > > > > Cf.
> > > > 
> > > > https://medium.com/@nikgraf/why-you-should-enforce-dangling-commas-for-multiline-statements-d034c98e36f8
> > > > > 
> > > > > I'd like to see this get in unless there are real technical issues
> > > > > blocking it. I don't think it's our place to block an optional
> > > > > extension on aesthetic grounds unless it was beyond the pale of what
> > > > > the language is or does. I don't see how an extension permitting extra
> > > > > commas would qualify.
> > > > > 
> > > > > 
> > > > > On Sat, Aug 4, 2018 at 10:37 AM, Joachim Breitner
> > > > > <mail at joachim-breitner.de> wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > Am Samstag, den 02.06.2018, 13:04 -0700 schrieb Iavor Diatchki:
> > > > > > > Well, I think it is a bad idea.  Obviously I don't think it has a
> > > > > > > huge impact on the language, but I think it encourages poor style,
> > > > > > > for very questionable befits.  This is quite subjective, of course,
> > > > > > > but I think that this choice is at odds with Haskell's elegant
> > > > > > > surface syntax.  We don't allow repeated punctuation in written
> > > > > > > prose,,,, why would we want in our programs?,,,
> > > > > > 
> > > > > > looks like there is some discussion needed here…
> > > > > > 
> > > > > > Cheers,
> > > > > > Joachim
> > > > > > 
> > > > > > 
> > > > > > --
> > > > > > Joachim Breitner
> > > > > >  mail at joachim-breitner.de
> > > > > >  http://www.joachim-breitner.de/
> > > > > > 
> > > > > > _______________________________________________
> > > > > > ghc-steering-committee mailing list
> > > > > > ghc-steering-committee at haskell.org
> > > > > > 
> > > > 
> > > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > --
> > > > > Chris Allen
> > > > > Currently working on http://haskellbook.com
> > > > 
> > > > 
> > > > 
> > > > --
> > > > Chris Allen
> > > > Currently working on http://haskellbook.com
> > > > _______________________________________________
> > > > 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
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180805/3e314ceb/attachment.sig>