[ghc-steering-committee] Extra Commas

[Simon Peyton Jones]

So I still think accepting this is a mistake, but if everyone else finds it useful, obviously, it is not something that will interfere with my use of Haskell in significant ways.
If it were just me I wouldn’t do it either.  But it seems important to some people, and it doesn’t harm anyone (provided we can avoid it interacting badly with tuple sections).  So I’m not going to stand in the way.

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Iavor Diatchki
Sent: 25 April 2019 18:43
To: Richard Eisenberg <rae at richarde.dev>
Cc: ghc-steering-committee at haskell.org
Subject: Re: [ghc-steering-committee] Extra Commas



On Thu, Apr 25, 2019 at 9:19 AM Richard Eisenberg <rae at richarde.dev<mailto:rae at richarde.dev>> wrote:


> On Apr 24, 2019, at 3:30 AM, Simon Marlow <marlowsd at gmail.com<mailto:marlowsd at gmail.com>> wrote:
>
> I'm not sure about allowing the combination of TupleSections and ExtraCommas. It would mean that (x,) has a different meaning depending on what extensions are in force.

While I agree that this situation is suboptimal, it already exists in multiple ways. For example `f $x` has different meanings depending on whether -XTemplateHaskell is enabled -- and sometimes, both would type-check but mean different things. `data T a = MkT` has a different meaning depending on whether -XPolyKinds is enabled, and this change is not strictly conservative due to the potential for ambiguity when generalizing. At top-level, `pattern Nothing = Just ()` has a different meaning depending on whether -XPatternSynonyms is enabled; both meanings are error-free. My point here is that this argument doesn't hold much sway, for me -- the cows have already left the pasture. (I do agree that letting yet another calf out isn't great, but it's not, to me, a self-standing argument for rejection.)

It seems that these are examples of things working differently depending on if an extension is on or not, which is not a problem because, well, this is the whole point of turning on the extension.   I don't think we have many examples where different extensions conflict with each other, so we'd probably want to write some code to report an error if both extensions are on, as clearly someone made a mistake.   Unfortunately, this does not work if you write all extensions in the cabal file, rather then enumerating them in each separate module, so maybe in that case we don't report an error.  Or we just arbitrarily order the extensions so that one takes precedence over the other...


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.

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,

   2. Cleaner "diffs"---I find this completely unconvincing because
        1) there are plenty of tools for working with diffs and an extra modified line when someone edits a list really make no difference,
        2) the use case we are optimizing for are: programs with lots of large list/tuple literals, where most of the edits are to add/remove/reorder the elements in those literals; how common are those, really?

   3. Easier support for CPP---also unconvincing as it is easy to work around by naming the parts of the list that may change; not only is this easy to do, but it likely makes the code more readable.  Note that the CPP use case likely does not apply to tuples, as if you comment out some of the fields, the whole type would change, and now you'd have to CPP all uses of the tuples as well.

So I still think accepting this is a mistake, but if everyone else finds it useful, obviously, it is not something that will interfere with my use of Haskell in significant ways.

-Iavor







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190425/46db17d2/attachment-0001.html>