[ghc-steering-committee] Extra Commas

[Christopher Allen]

My understanding of previous discussions was that:

"tuples included" means "incompatible with tuple sections" means "they
are mutually exclusive to a module."

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
> |  > >  http://www.joachim-breitner.de/
> |  > >
> |  > >
> |  > > _______________________________________________
> |  > > ghc-steering-committee mailing list
> |  > > ghc-steering-committee at haskell.org
> |  > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-commi
> |  > > ttee
> |  > >
> |  > > Attachments:
> |  > > * signature.asc
> |  > _______________________________________________
> |  > ghc-steering-committee mailing list
> |  > ghc-steering-committee at haskell.org
> |  > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committ
> |  > ee
> |
> |
> |
> |  --
> |  Chris Allen
> |  Currently working on http://haskellbook.com
> |  _______________________________________________
> |  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