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

[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