[ghc-steering-committee] Extra Commas
Richard Eisenberg
rae at richarde.dev
Thu Apr 18 15:06:10 UTC 2019
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
More information about the ghc-steering-committee
mailing list