[ghc-steering-committee] Extra Commas

[Iavor Diatchki]

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

>
>
> > On Apr 24, 2019, at 3:30 AM, Simon Marlow <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/7342781d/attachment.html>