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

[Eric Seidel]

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