[ghc-steering-committee] Extra Commas

[Simon Peyton Jones]

Just to remind everyone, here's the proposal
https://github.com/parsonsmatt/ghc-proposals/blob/trailing-leading-commas/proposals/0000-trailing-leading-commas-subexports.rst

I think the TupleSections conflict means that the proposal does *not* plan to allow leading or trailing commas in tuples.  That's an exception, but has no other technical difficulty.

I wonder if, for uniformity, the same exception should be made for constraint tuples, disallowing
	f :: (Monad m,) => blah
because constraint tuples *are* really just tuples, and perhaps (Monad m,) :: Constraint -> Constraint.

The proposal has a "maybe" for pattern guards, so we don't have a clear recommendation from the author there.

But aside from these points I see not great difficulty.  It's a superficial syntactic change (like putting 'qualified' in a different place; some people like it, and no harm is done to people who don't want it.

Simon

|  -----Original Message-----
|  From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
|  On Behalf Of Joachim Breitner
|  Sent: 17 April 2019 23:31
|  To: ghc-steering-committee at haskell.org
|  Subject: Re: [ghc-steering-committee] Extra Commas
|  
|  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/