Re: [ghc-steering-committee] Bang patterns: 343

Dear all, I agree that this proposal doesn't make that much sense on its own. But it does raise a good point. Maybe it's a sign that it's time to have a conversation about defaults. I don't know where and how this conversation ought to take place. But maybe GHC's default need not be those of Haskell 2010. On Tue, Jul 28, 2020 at 10:20 AM Tom Harding wrote:

Seconded, and very keen on the idea of collective synonyms as a more lightweight alternative to regularly-updated language specifications.

Cheers, Tom

On 28 Jul 2020, at 09:13, Alejandro Serrano Mena wrote:

I agree with the rejection. My main concern, as shared by others in the thread, is why this specific extension and not others.

I am really looking forward to the addition of synonyms for a bunch of extensions. Personally, I would love to see a way to enable every "additive" extension (I am thinking of MultiParamTypeClasses + FlexibleThings + ViewAndBangPatterns + ...). I would be happy to help with setting up the process.

Regards, Alejandro

El mar., 28 jul. 2020 a las 10:03, Simon Peyton Jones via ghc-steering-committee () escribió:

...

Friends

Despite asking, I’m not seeing any support for proposal 343 “Enable bang patterns by default https://github.com/ghc-proposals/ghc-proposals/pull/343”, except from the author. He makes a good case, but I think it’s a case that you could make for quite a few extensions.

I propose that we reject the proposal as written. Any objections?

That leaves the wider question, best summarised by Joachim’s post https://github.com/ghc-proposals/ghc-proposals/pull/343#issuecomment-6646313...: we could occasionally add a new synonym for a bunch of extensions. I suppose we’d have to (a) debate and decide that process and (b) execute on the process. Perhaps that’d be useful but it’s all work. Let’s first see if there is real support for doing it. If so, probably the best thing would be for someone who wants it to happen to write a proposal (as Joachim has started) describing the process.

Simon

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee