Just to remind everyone, here's the proposal https://github.com/parsonsmatt/ghc-proposals/blob/trailing-leading-commas/pr... 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@haskell.org> | On Behalf Of Joachim Breitner | Sent: 17 April 2019 23:31 | To: ghc-steering-committee@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@joachim-breitner.de | http://www.joachim-breitner.de/