[ghc-steering-committee] Extra Commas
Christopher Allen
cma at bitemyapp.com
Mon Jul 8 18:14:58 UTC 2019
Restating my point more explicitly: if you implemented the extension
as described post-modification: I wouldn't enable it and I'm one of
the biggest fans of Rust's syntax in this respect. I use Rust for fun
and for work right now.
A follow-up thought for this: the opinions and priorities of people
who simply didn't want the extension or didn't plan to use it weighed
heavily on where the proposal went. This took it places nobody
interested in the proposal was interested in moving forward with. We
might want to consider how we evaluate proposals in light of that
problem. In the past I've held off commenting on proposals I wasn't
interested in but considered benign to my priorities. I don't think
everyone is operating on the same principle and it's making the
process more bureaucratic and less effective for helping Haskell users
achieve their ends.
On Mon, Jul 8, 2019 at 1:05 PM Christopher Allen <cma at bitemyapp.com> wrote:
>
> To reiterate nobody wants that or is interested in a partial solution.
> The original proposer included. Neither of us are interested in
> editing or implementing the post-modification proposal. I'd like to
> return to the original proposer's final intent: closing the issue as
> rejected. I'd sooner sit on it and wait for a time when it won't get
> mutilated. A partial solution means a full implementation has zero
> chance of getting accepted.
>
> If there are no objections, I will re-close the proposal as rejected.
>
> On Mon, Jul 8, 2019 at 5:23 AM Simon Peyton Jones via
> ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
> >
> > I’m ok with accepting, but excluding tuples, including constraint tuples.
> >
> >
> >
> > I’m be ok with excluding list literals too.
> >
> >
> >
> > We should ask the author if s/he feels that these exclusions would unacceptably eviscerate the proposal i.e. make it not worth doing.
> >
> >
> >
> > The upside is that it’s clearly a superficial, syntax-only issue. Nothing deep is at stake here.
> >
> >
> >
> > Simon
> >
> >
> >
> > From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Vitaly Bragilevsky
> > Sent: 24 April 2019 20:20
> > To: ghc-steering-committee at haskell.org
> > Subject: Re: [ghc-steering-committee] Extra Commas
> >
> >
> >
> > I am next voting to accept this proposal, not covering tuples.
> >
> >
> >
> > Vitaly
> >
> >
> >
> > ср, 24 апр. 2019 г. в 19:17, Manuel M T Chakravarty <chak at justtesting.org>:
> >
> > As I have said previously, I strongly agree with Simon on that we need to make some editorial decisions.
> >
> >
> >
> > Concerning the general proposal, I think, the convenience of trailing commas is a consequence of insufficient editor support and IMHO it’d be better to improve that support rather than applying band-aids to the language. However, I can live with the extensions as long as their is no conflict with TupleSections.
> >
> >
> >
> > Cheers,
> >
> > Manuel
> >
> >
> >
> > Am 24.04.2019 um 09:30 schrieb Simon Marlow <marlowsd at gmail.com>:
> >
> >
> >
> > I'm also strongly against mutually incompatible extensions.
> >
> >
> >
> > 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. This is a pretty strange direction to take the language in, and raises questions about whether we should think of GHC as a testing ground for language extensions of which only some will eventually make it into a language standard, or whether we should take a position on which extensions are sensible when there are conflicts. Personally I'm in favour of the committee taking some editorial decisions here - not just assessing which extensions make sense in isolation, but considering whether an extension makes sense in the context of the other extensions we already have.
> >
> >
> >
> > But back to the current proposal, I would vote for allowing the parts of the proposal that don't conflict with TupleSections.
> >
> >
> >
> > Cheers
> >
> > Simon
> >
> >
> >
> > On Thu, 18 Apr 2019 at 16:06, Richard Eisenberg <rae at richarde.dev> wrote:
> >
> > I strongly dislike the idea of mutually-incompatible extensions.
> >
> > We could say that ExtraCommas allows extra commas everywhere, including in tuples and lists. We could also say that TupleSections overrides this behavior in tuples and gives it new meaning. We could further imagine ListSections that would override the behavior in lists. To me, this is preferable than mutual incompatibility.
> >
> > Does this make for a nice user experience? I'm not sure. Happily, the reinterpretation from TupleSections or ListSections would change types, so you'd get errors up front. These errors might even be clever enough to notice that both ExtraCommas and TupleSections are in effect and gently remind the user that this combination can be confusing. Actually, this might be a nice "have your cake and eat it too" moment: let's just do all the things!
> >
> > Richard
> >
> > > On Apr 18, 2019, at 10:52 AM, Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
> > >
> > > | "tuples included" means "incompatible with tuple sections" means "they are
> > > | mutually exclusive to a module."
> > >
> > > You mean, some kind of new error message that says "these two extension are mutually incompatible". I can't say I love this. Let's just leave out tuples from ExtraCommas.
> > >
> > > (Actually I could imagine [a,,b,] meaning \xy. [a,x,b,y], one day. Maybe we omit list literals too? Or would that break the key use-cases?
> > >
> > > Simon
> > >
> > > | -----Original Message-----
> > > | From: Christopher Allen <cma at bitemyapp.com>
> > > | Sent: 18 April 2019 10:08
> > > | To: Simon Peyton Jones <simonpj at microsoft.com>
> > > | Cc: Eric Seidel <eric at seidel.io>; ghc-steering-committee at haskell.org
> > > | Subject: Re: [ghc-steering-committee] Extra Commas
> > > |
> > > | My understanding of previous discussions was that:
> > > |
> > > |
> > > | On Thu, Apr 18, 2019 at 2:17 AM Simon Peyton Jones <simonpj at microsoft.com>
> > > | wrote:
> > > | >
> > > | > But it's actually *incompatible* with TupleSections, so how shoule
> > > | > (True,)
> > > | > be interpreted if both are on?
> > > | >
> > > | > S
> > > | >
> > > | > | -----Original Message-----
> > > | > | From: ghc-steering-committee
> > > | > | <ghc-steering-committee-bounces at haskell.org>
> > > | > | On Behalf Of Christopher Allen
> > > | > | Sent: 18 April 2019 04:19
> > > | > | To: Eric Seidel <eric at seidel.io>
> > > | > | Cc: ghc-steering-committee at haskell.org
> > > | > | Subject: Re: [ghc-steering-committee] Extra Commas
> > > | > |
> > > | > | I spoke with Matt, he's fine either way with or without tuples.
> > > | > |
> > > | > | I'd prefer "with tuples" for consistency. I use tuples sometimes,
> > > | > | but don't care about sectioning.
> > > | > |
> > > | > | On Wed, Apr 17, 2019 at 8:15 PM Eric Seidel <eric at seidel.io> wrote:
> > > | > | >
> > > | > | > I favor accepting the proposal, with or without tuples. I've been
> > > | > | writing a bit of Rust recently, and agree with Chris about the
> > > | > | ergonomics of trailing commas.
> > > | > | >
> > > | > | > On Wed, Apr 17, 2019, at 18:31, Joachim Breitner wrote:
> > > | > | > > Hi,
> > > | > | > >
> > > | > | > > Am Mittwoch, den 17.04.2019, 13:38 -0500 schrieb Christopher
> > > | Allen:
> > > | > | > > > I gave my recommendation for ExtraCommas, acceptance of the
> > > | > | > > > original proposal as written. I talk with the proposer almost
> > > | > | > > > every day so I know where he stands. He still thinks it's
> > > | > | worth > > > doing and would like to see it accepted. I think
> > > | > | ExtraCommas > > > merits acceptance. If we can't achieve consensus
> > > | > | on it then it > > > should be rejected so it gets cleared off the
> > > | > | slate. I'm not > > > inclined to argue a syntactic extension like
> > > | > | this, but I will say
> > > | > | this:
> > > | > | > > >
> > > | > | > > > The proposal captures a nice design element that we've seen
> > > | > | work > > > very well ergonomically in Rust. We're never going to
> > > | > | make the > > > same decisions with the same tradeoffs as a totally
> > > | > | different > > > language but any time there is a relatively isolated
> > > | "good idea"
> > > | > | > > > like this, I'd like to see us try to take advantage of that
> > > | > | and > > > see if it works for us.
> > > | > | > >
> > > | > | > > thanks for picking this up.
> > > | > | > >
> > > | > | > > The most contentious point, besides whether its worth the
> > > | > | bother at > > all, was the interaction with TupleSections. Which
> > > | > | gives us three > > options, I think:
> > > | > | > > * reject
> > > | > | > > * accept, covering tuples (and making it conflict with > >
> > > | > | TupleSections) > > * accept, not covering tuples.
> > > | > | > >
> > > | > | > > No decision is absolutely wrong, none is obviously right.
> > > | > | > >
> > > | > | > > Maybe we should simply do a vote, to get it decided? Simons (as
> > > | > | > > Chairs), what do you think?
> > > | > | > >
> > > | > | > > Cheers,
> > > | > | > > Joachim
> > > | > | > >
> > > | > | > > --
> > > | > | > > Joachim Breitner
> > > | > | > > mail at joachim-breitner.de
> > > | > | > >
> > > | > | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww
> > > | > | .joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7
> > > | > | C670f986836834427a29408d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47
> > > | > | %7C1%7C0%7C636911752855987147&sdata=gCdvqR5gm0K54rJMnfcnIiOyyv4u
> > > | > | 9fb%2BRkQMqGibDlM%3D&reserved=0
> > > | > | > >
> > > | > | > >
> > > | > | > > _______________________________________________
> > > | > | > > ghc-steering-committee mailing list > >
> > > | > | ghc-steering-committee at haskell.org
> > > | > | > >
> > > | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma
> > > | > | il.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-commi&a
> > > | > | mp;data=02%7C01%7Csimonpj%40microsoft.com%7C670f986836834427a29408d6
> > > | > | c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63691175285598
> > > | > | 7147&sdata=NZqChpNEoHihvoow29uxmmDyPuLeVgn4iNwkcdMDno8%3D&re
> > > | > | served=0
> > > | > | > > ttee
> > > | > | > >
> > > | > | > > Attachments:
> > > | > | > > * signature.asc
> > > | > | > _______________________________________________
> > > | > | > ghc-steering-committee mailing list >
> > > | > | ghc-steering-committee at haskell.org
> > > | > | >
> > > | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma
> > > | > | il.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committ
> > > | > | &data=02%7C01%7Csimonpj%40microsoft.com%7C670f986836834427a29408
> > > | > | d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636911752855
> > > | > | 987147&sdata=1PZCPlMWYOlGrlN7MFkvn7rmpdMUqv%2BShDLpFyO4Y%2FI%3D&
> > > | > | amp;reserved=0
> > > | > | > ee
> > > | > |
> > > | > |
> > > | > |
> > > | > | --
> > > | > | Chris Allen
> > > | > | Currently working on
> > > | > | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhas
> > > | > | kellbook.com&data=02%7C01%7Csimonpj%40microsoft.com%7C670f986836
> > > | > | 834427a29408d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C
> > > | > | 636911752855987147&sdata=u6TzKujVuJnrWL%2BnPr0YlcE7w8xHnENsWZUDK
> > > | > | 8IyjBI%3D&reserved=0
> > > | > | _______________________________________________
> > > | > | ghc-steering-committee mailing list
> > > | > | ghc-steering-committee at haskell.org
> > > | > |
> > > | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma
> > > | > | il.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committ
> > > | > | ee&data=02%7C01%7Csimonpj%40microsoft.com%7C670f986836834427a294
> > > | > | 08d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6369117528
> > > | > | 55987147&sdata=ESnHSYRuMMUvenMjIzpapcKWVfzbAqLJ9%2BcSNjoWklk%3D&
> > > | > | amp;reserved=0
> > > |
> > > |
> > > |
> > > | --
> > > | Chris Allen
> > > | Currently working on
> > > | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskellbo
> > > | ok.com&data=02%7C01%7Csimonpj%40microsoft.com%7C670f986836834427a29408
> > > | d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636911752855987147
> > > | &sdata=u6TzKujVuJnrWL%2BnPr0YlcE7w8xHnENsWZUDK8IyjBI%3D&reserved=0
> > > _______________________________________________
> > > 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
> >
> >
> >
> > _______________________________________________
> > 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
>
>
>
> --
> Chris Allen
> Currently working on http://haskellbook.com
--
Chris Allen
Currently working on http://haskellbook.com
More information about the ghc-steering-committee
mailing list