Bang patterns: 343

Simon Peyton Jones

28 Jul 2020 28 Jul '20

4:03 a.m.

Friends Despite asking, I'm not seeing any support for proposal 343 "Enable bang patterns by defaulthttps://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 posthttps://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

Attachments:

attachment.html (text/html — 2.9 KB)

Show replies by date

Alejandro Serrano Mena

28 Jul 28 Jul

4:13 a.m.

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

Tom Harding

4:19 a.m.

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 mailto:trupill@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 (mailto:ghc-steering-committee@haskell.org>) escribió: Friends Despite asking, I’m not seeing any support for proposal 343 “Enable bang patterns by defaulthttps://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 posthttps://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.orgmailto: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.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Tom Harding

4:19 a.m.

Spiwack, Arnaud

5:05 a.m.

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

Joachim Breitner

29 Aug 29 Aug

11:28 a.m.

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 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”, 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@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

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

1725

Age (days ago)

1757

Last active (days ago)

List overview

Download

5 comments

5 participants

participants (5)

Alejandro Serrano Mena
Joachim Breitner
Simon Peyton Jones
Spiwack, Arnaud
Tom Harding