[ghc-steering-committee] Extra Commas

[Eric Seidel]

On Thu, Apr 25, 2019, at 13:43, Iavor Diatchki wrote:
> On Thu, Apr 25, 2019 at 9:19 AM Richard Eisenberg <rae at richarde.dev> wrote:
> >  So my vote is to have both, but do not interpret this as a vote against "everything but tuples", which seems to be gaining momentum.
> > 
> What we seem to be discussing is a specification that would read 
> something like this: 1) "(a,)" is an error, unless (2) "tuple sections" 
> are one, in which case it is a function, unless (3) "extra commas" is 
> on, in which case it just means "a", or maybe with (2) and (3) swapped. 
> Ugh. And, presumably having "extra commas" work on tuples, would be 
> useful if one had some really big tuples, and didn't want to delete the 
> extra comma at the end. Having really big tuples does not make programs 
> easier to read and manipulate, so I question what sort of programs are 
> we trying to make easier to write.

Indeed, big tuples are suspicious, and I think the least compelling use-case for ExtraCommas. Which is why I would not be bothered if we left tuples out of the extension.

> >  PS: I agree that this is a matter of editor support, and I'm not a fan of extra commas. But I hear a chorus of voices asking for this feature, and so I'm inclined to go with the wisdom of the crowd here.
> > 
> Well, I remain completely unconvinced by the wisdom of the crowd in 
> this case, at least for "extra commas" in the expression language. The 
> main reasoning I've see in the discussion are:
> 
>  1. Improved "ergonomics", but I am not sure what that means,

I believe I'm one of the people who mentioned ergonomics, so let me try to elaborate.

A number of people have commented that it feels like the problem ExtraCommas is trying to address would be better solved by better editors. I don't really disagree with this, but we don't have better editors. People have been working on structured editors for decades, but they haven't really panned out. I think the most successful example of a structured editor might emacs' paredit (and the newer smartparens), and they work well precisely because of the minimal syntax of lisp.

The editors that we have today are by and large line-oriented, which makes operations on entire lines very easy. For example, if I have a large list or record

  foo = [
    1,
    2,
    3,
    4
  ]

it usually takes only a few keystrokes to add/delete/reorder elements. This is very convenient, but it starts to break down if I have to interact with the last element, 4. I cannot delete 4, or swap it with another element using the standard line-oriented commands, because the result will be syntactically invalid. So, what should be a very routine (and boring) part of my job as a programmer becomes just a bit more tedious. If we allow trailing commas, this issue goes away entirely.

It is a small issue, granted, but it's one that you run into regularly, at least I do. And it wears on you over time. This is why I claim ExtraCommas improves the ergonomics of Haskell's syntax.

Eric