[ghc-steering-committee] Bang patterns: 343

[Joachim Breitner]

Hi,

a bit late to act, but it seems we have clear consensus about rejecting
this in the current form. Marking as such.

Cheers,
Joachim

Am Dienstag, den 28.07.2020, 11:05 +0200 schrieb Spiwack, Arnaud:
> 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 <tomjharding at live.co.uk> 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 <trupill at gmail.com> 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 (<ghc-steering-committee at haskell.org>) escribió:
> > > > Friends
> > > > Despite asking, I’m not seeing any support for proposal 343 “Enable bang patterns by default”, 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: 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 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
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/