[ghc-steering-committee] Extra Commas
Vitaly Bragilevsky
bravit111 at gmail.com
Wed Apr 24 19:20:12 UTC 2019
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190424/c7f80f2d/attachment-0001.html>
More information about the ghc-steering-committee
mailing list