Why not?, rather than, why?

newer
Please review #555: Higher Order...

Joachim Breitner

2 Dec 2022 2 Dec '22

11:06 a.m.

Hello Committee and Community, occasionally we have meta-discussions about GHC language extensions: Should they be allowed to be fork-like, where some extensions are unlikely to be used together and some stay opt-in forever? Or should (ideally) every extension be on track to become on-by-default. Of course there are a few “old” extensions that by their very nature are not suitable to be on by default (SAFE, TRUSTWORTHY and CPP are the obvious candidates). Let’s put them aside for this discussion. I’d wager that if we’d introduce them these days, they wouldn’t be language extensions in the first place, but maybe modifiers on the module. I am mostly in the camp “every extension should be on track to become default (or be discarded)”. Once a language feature has been proven useful and reasonable stable, I see little value in requiring programmers to jump through hoops to use them. Is that the prevalent view here as well, or do we have a strong camp saying that our current “pick-and-choose” approach to language features is actually a good thing in its own (and not just a necessary nuisance)? If we assume the former, then maybe it would be worth to frame the discussion around new language extensions, and the discussion about which language extensions become default, around that vision. Concretely: * A new language proposal should not just be good enough for “worth building for those who explicitly turn it on”, but really ought convince as “this will make Haskell better for all” (and not just “a Haskell”). * Most new language features should probably not on by default initially, as usual, and are initially experimental. But then the proposal, and if accepted the documentation of the extension, should as explicit as possible explain why it is not yet default: What needs to happen for _this_ extension to be considered ready – or judged negatively and put on a track towards removal. This could be something like “been available for n releases, been stable for m releases”. (I wonder what other kind of criteria to expect here?) * The process for defining GHC20xx would then become very different: We’d go through all experimental extensions, check if the criteria are satisfied, maybe apply some common sense if the criteria are still good ones, and turn it on if so. This may turn the process to be more structured and maybe more predictable, and hopefully reduces the number of non-default extensions developers have to make a decision about (probably good). But it does raise the bar for new language features (is that good?). And, if applied consequently, it suggests to deprecate and eventually remove extensions that turn out to not be default-worthy after all (that’s kinda harsh)? As you can see I am a bit unsure about what the criteria are that we could put in the docs. Are they really different for different extensions? But the fact that its hard to come up right now with a concrete reason why extension X is not yet the default does point to a hole in our thinking and our process! And it is the same question that we face when discussing GHC20xx. So I guess what I am proposing here is: Have that discussion (when is it ready?) already when accepting a proposal, and document it in clear sight for our users, rather than have it over and over when debating GHC20xx. This is not a concrete (meta-)proposal, but hopefully tasty food for thought. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Show replies by date

Arnaud Spiwack

2 Dec 2 Dec

3:06 p.m.

I believe that I've been vocal in the past about my view that extensions should eventually become on by default. And even about the fact that I struggle to understand the point of view of extensions as configuration switches. I have no idea, however, how numerous each side of this debate is, nor how strongly the beliefs are held (very strongly in my case, obviously, but I don't know for others). I think that you're right, Joachim, and that it's time to make a definite decision about that and make the decision one of our Principles. If we come to the side that extensions are to eventually become defaults, I agree that the question of how to deprecate extensions that will never make it to the default is something that we have to tackle. A slightly more difficult discussion is how do we deprecate things that used to be the default. Imagine, say, that we want to make `-XMonoLocalBinds` the default, `-XMonoLocalBinds` is really removing a feature (as such it should probably be named something like `-XNoGeneralizeLocaBinds`), what does the deprecation period look like? Maybe it's actually the same question as deprecating a non-default extension, but maybe not. On Fri, 2 Dec 2022 at 12:07, Joachim Breitner wrote:

...

Hello Committee and Community,

occasionally we have meta-discussions about GHC language extensions: Should they be allowed to be fork-like, where some extensions are unlikely to be used together and some stay opt-in forever? Or should (ideally) every extension be on track to become on-by-default.

Of course there are a few “old” extensions that by their very nature are not suitable to be on by default (SAFE, TRUSTWORTHY and CPP are the obvious candidates). Let’s put them aside for this discussion. I’d wager that if we’d introduce them these days, they wouldn’t be language extensions in the first place, but maybe modifiers on the module.

I am mostly in the camp “every extension should be on track to become default (or be discarded)”. Once a language feature has been proven useful and reasonable stable, I see little value in requiring programmers to jump through hoops to use them.

Is that the prevalent view here as well, or do we have a strong camp saying that our current “pick-and-choose” approach to language features is actually a good thing in its own (and not just a necessary nuisance)?

If we assume the former, then maybe it would be worth to frame the discussion around new language extensions, and the discussion about which language extensions become default, around that vision. Concretely:

* A new language proposal should not just be good enough for “worth building for those who explicitly turn it on”, but really ought convince as “this will make Haskell better for all” (and not just “a Haskell”).

* Most new language features should probably not on by default initially, as usual, and are initially experimental. But then the proposal, and if accepted the documentation of the extension, should as explicit as possible explain why it is not yet default: What needs to happen for _this_ extension to be considered ready – or judged negatively and put on a track towards removal.

This could be something like “been available for n releases, been stable for m releases”. (I wonder what other kind of criteria to expect here?)

* The process for defining GHC20xx would then become very different: We’d go through all experimental extensions, check if the criteria are satisfied, maybe apply some common sense if the criteria are still good ones, and turn it on if so.

This may turn the process to be more structured and maybe more predictable, and hopefully reduces the number of non-default extensions developers have to make a decision about (probably good). But it does raise the bar for new language features (is that good?). And, if applied consequently, it suggests to deprecate and eventually remove extensions that turn out to not be default-worthy after all (that’s kinda harsh)?

As you can see I am a bit unsure about what the criteria are that we could put in the docs. Are they really different for different extensions? But the fact that its hard to come up right now with a concrete reason why extension X is not yet the default does point to a hole in our thinking and our process!

And it is the same question that we face when discussing GHC20xx. So I guess what I am proposing here is: Have that discussion (when is it ready?) already when accepting a proposal, and document it in clear sight for our users, rather than have it over and over when debating GHC20xx.

This is not a concrete (meta-)proposal, but hopefully tasty food for thought.

Cheers, Joachim

-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

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

Simon Peyton Jones

4:03 p.m.

...

I think that you're right, Joachim, and that it's time to make a definite decision about that and make the decision one of our Principles.

I'm not sure we can make it completely black and white. Punning is an example. Some people Really Want to use punning (have a data type and a data constructor with the same name). Others Really Do Not Want punning because they want to do lots of dependently typed programing. They don't-want it so much that they want warnings if they accidentally use it. (Simply refraining from punning is not enough for them.) Neither group is wrong... it's simply a stylistic choice. But if we solidly adopt one choice or the other, we are privileging one group over the other, which to me seems like risking unnecessary conflict, one that could absorb precious cycles we could more profitably spend elsewhere. Simon On Fri, 2 Dec 2022 at 15:06, Arnaud Spiwack wrote:

...

I believe that I've been vocal in the past about my view that extensions should eventually become on by default. And even about the fact that I struggle to understand the point of view of extensions as configuration switches. I have no idea, however, how numerous each side of this debate is, nor how strongly the beliefs are held (very strongly in my case, obviously, but I don't know for others).

I think that you're right, Joachim, and that it's time to make a definite decision about that and make the decision one of our Principles.

If we come to the side that extensions are to eventually become defaults, I agree that the question of how to deprecate extensions that will never make it to the default is something that we have to tackle. A slightly more difficult discussion is how do we deprecate things that used to be the default. Imagine, say, that we want to make `-XMonoLocalBinds` the default, `-XMonoLocalBinds` is really removing a feature (as such it should probably be named something like `-XNoGeneralizeLocaBinds`), what does the deprecation period look like? Maybe it's actually the same question as deprecating a non-default extension, but maybe not.

On Fri, 2 Dec 2022 at 12:07, Joachim Breitner wrote:

...
Hello Committee and Community,

occasionally we have meta-discussions about GHC language extensions: Should they be allowed to be fork-like, where some extensions are unlikely to be used together and some stay opt-in forever? Or should (ideally) every extension be on track to become on-by-default.

Of course there are a few “old” extensions that by their very nature are not suitable to be on by default (SAFE, TRUSTWORTHY and CPP are the obvious candidates). Let’s put them aside for this discussion. I’d wager that if we’d introduce them these days, they wouldn’t be language extensions in the first place, but maybe modifiers on the module.

I am mostly in the camp “every extension should be on track to become default (or be discarded)”. Once a language feature has been proven useful and reasonable stable, I see little value in requiring programmers to jump through hoops to use them.

Is that the prevalent view here as well, or do we have a strong camp saying that our current “pick-and-choose” approach to language features is actually a good thing in its own (and not just a necessary nuisance)?

If we assume the former, then maybe it would be worth to frame the discussion around new language extensions, and the discussion about which language extensions become default, around that vision. Concretely:

* A new language proposal should not just be good enough for “worth building for those who explicitly turn it on”, but really ought convince as “this will make Haskell better for all” (and not just “a Haskell”).

* Most new language features should probably not on by default initially, as usual, and are initially experimental. But then the proposal, and if accepted the documentation of the extension, should as explicit as possible explain why it is not yet default: What needs to happen for _this_ extension to be considered ready – or judged negatively and put on a track towards removal.

This could be something like “been available for n releases, been stable for m releases”. (I wonder what other kind of criteria to expect here?)

* The process for defining GHC20xx would then become very different: We’d go through all experimental extensions, check if the criteria are satisfied, maybe apply some common sense if the criteria are still good ones, and turn it on if so.

This may turn the process to be more structured and maybe more predictable, and hopefully reduces the number of non-default extensions developers have to make a decision about (probably good). But it does raise the bar for new language features (is that good?). And, if applied consequently, it suggests to deprecate and eventually remove extensions that turn out to not be default-worthy after all (that’s kinda harsh)?

As you can see I am a bit unsure about what the criteria are that we could put in the docs. Are they really different for different extensions? But the fact that its hard to come up right now with a concrete reason why extension X is not yet the default does point to a hole in our thinking and our process!

And it is the same question that we face when discussing GHC20xx. So I guess what I am proposing here is: Have that discussion (when is it ready?) already when accepting a proposal, and document it in clear sight for our users, rather than have it over and over when debating GHC20xx.

This is not a concrete (meta-)proposal, but hopefully tasty food for thought.

Cheers, Joachim

-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ 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

4:39 p.m.

Hi, Am Freitag, dem 02.12.2022 um 16:03 +0000 schrieb Simon Peyton Jones:

...

Neither group is wrong... it's simply a stylistic choice. But if we solidly adopt one choice or the other, we are privileging one group over the other, which to me seems like risking unnecessary conflict, one that could absorb precious cycles we could more profitably spend elsewhere.

but that amounts to saying that our vision for GHC is to support multiple languages, and not just by saying “some still experimental features are opt-in”, but really “There are different Haskell-like source languages you can choose from”. That is a justifiable stance! But it is a stance that’s incompatible with “we want there to be one Haskell language” (surely with different programming styles, but still one default stable language). And I believe it would be good to gain more clarity here. For example, if we’d go that route (which I am not fully opposed to, either!), I could imagine embracing it even more, and paying more attention to which language extensions are * module-local (i.e. define locally a new language syntax, but don’t affect the interface between modules), and which * cross the module boundary. Most syntactic gadgets (UnicodeSyntax, Punning) are of the former, most type system change (ExistentialTypes…) are of the latter. The former we can be much more liberal if we embrace the idea of that every programmer can have their own preferred dialect to write their Haskell code in, as they still participate in the wider ecosystem of existing Haskell code. To the extent that I would humor a proposal of LispyHaskell that proposes a completely new syntax with lots of parentheses, as long as it still behaves the same on the module boundary! Maybe an extreme example, but why not? (Is it too dangerous to call the two stances towards dialects the French and the German approach? :-)) Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Simon Marlow

4:43 p.m.

I also think I've been pretty vocal in the past about favouring the view that extensions should be on a path to being on by default - indeed in the language standard, if we ever have another one of those. Taking this approach more literally than we do would lead to difficult choices. Choices that penalise sections of the community with particular preferences. However, *not* making those choices penalises the whole community, perhaps not as visibly: more choices leads to a greater cognitive load, a longer learning curve, a greater barrier to entry off of which many potential users will bounce. And for us compiler developers, more alternatives and combinations to consider and test for, with more surprising emergent behaviours, more bugs and more work to do. In my view, if we want greater adoption we have to be opinionated: make difficult decisions that remove choices and streamline the language. At the very least, don't add more choices. But to Joachim's specific question: yes I like the idea of considering the "when will it be ready?" question for each extension, to precompute the input to the GHC20xx process. Cheers Simon On Fri, 2 Dec 2022 at 15:06, Arnaud Spiwack wrote:

...

I believe that I've been vocal in the past about my view that extensions should eventually become on by default. And even about the fact that I struggle to understand the point of view of extensions as configuration switches. I have no idea, however, how numerous each side of this debate is, nor how strongly the beliefs are held (very strongly in my case, obviously, but I don't know for others).

I think that you're right, Joachim, and that it's time to make a definite decision about that and make the decision one of our Principles.

If we come to the side that extensions are to eventually become defaults, I agree that the question of how to deprecate extensions that will never make it to the default is something that we have to tackle. A slightly more difficult discussion is how do we deprecate things that used to be the default. Imagine, say, that we want to make `-XMonoLocalBinds` the default, `-XMonoLocalBinds` is really removing a feature (as such it should probably be named something like `-XNoGeneralizeLocaBinds`), what does the deprecation period look like? Maybe it's actually the same question as deprecating a non-default extension, but maybe not.

On Fri, 2 Dec 2022 at 12:07, Joachim Breitner wrote:

...
Hello Committee and Community,

occasionally we have meta-discussions about GHC language extensions: Should they be allowed to be fork-like, where some extensions are unlikely to be used together and some stay opt-in forever? Or should (ideally) every extension be on track to become on-by-default.

Of course there are a few “old” extensions that by their very nature are not suitable to be on by default (SAFE, TRUSTWORTHY and CPP are the obvious candidates). Let’s put them aside for this discussion. I’d wager that if we’d introduce them these days, they wouldn’t be language extensions in the first place, but maybe modifiers on the module.

I am mostly in the camp “every extension should be on track to become default (or be discarded)”. Once a language feature has been proven useful and reasonable stable, I see little value in requiring programmers to jump through hoops to use them.

Is that the prevalent view here as well, or do we have a strong camp saying that our current “pick-and-choose” approach to language features is actually a good thing in its own (and not just a necessary nuisance)?

If we assume the former, then maybe it would be worth to frame the discussion around new language extensions, and the discussion about which language extensions become default, around that vision. Concretely:

* A new language proposal should not just be good enough for “worth building for those who explicitly turn it on”, but really ought convince as “this will make Haskell better for all” (and not just “a Haskell”).

* Most new language features should probably not on by default initially, as usual, and are initially experimental. But then the proposal, and if accepted the documentation of the extension, should as explicit as possible explain why it is not yet default: What needs to happen for _this_ extension to be considered ready – or judged negatively and put on a track towards removal.

This could be something like “been available for n releases, been stable for m releases”. (I wonder what other kind of criteria to expect here?)

* The process for defining GHC20xx would then become very different: We’d go through all experimental extensions, check if the criteria are satisfied, maybe apply some common sense if the criteria are still good ones, and turn it on if so.

This may turn the process to be more structured and maybe more predictable, and hopefully reduces the number of non-default extensions developers have to make a decision about (probably good). But it does raise the bar for new language features (is that good?). And, if applied consequently, it suggests to deprecate and eventually remove extensions that turn out to not be default-worthy after all (that’s kinda harsh)?

As you can see I am a bit unsure about what the criteria are that we could put in the docs. Are they really different for different extensions? But the fact that its hard to come up right now with a concrete reason why extension X is not yet the default does point to a hole in our thinking and our process!

And it is the same question that we face when discussing GHC20xx. So I guess what I am proposing here is: Have that discussion (when is it ready?) already when accepting a proposal, and document it in clear sight for our users, rather than have it over and over when debating GHC20xx.

This is not a concrete (meta-)proposal, but hopefully tasty food for thought.

Cheers, Joachim

-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ 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

Chris Dornan

5:27 p.m.

While I can see the value of expecting proposed extensions to finally be always on I am skeptical that we will be able to just force the community to accept that each extensions is going to be either binned or always on. It doesn’t, for me, fit with the history of Haskell and GHC being an open platform that encourages experimentation. (I don’t want to sideline the discussion by offering examples but I am sure we can all think of extensions in the gray zone that we like to break out on occasion or use extensively that would be contentious candidates for permanent enablement.) I am sympathetic to the idea of a new language standard that we promote heavily and encourage developers, tools, tutorials and courseware to favour —if we get this right then we will reap the benefits of a strong standard. But if we take it upon ourselves to try and force an extension combination of our choosing on the community because we believe the community will benefit from a big reset then I think it could blow up on us really badly, with forks and factions which could be truly difficult to manage — and fatally discourage adoption. Chris

...

On 2 Dec 2022, at 16:43, Simon Marlow wrote:

I also think I've been pretty vocal in the past about favouring the view that extensions should be on a path to being on by default - indeed in the language standard, if we ever have another one of those.

Taking this approach more literally than we do would lead to difficult choices. Choices that penalise sections of the community with particular preferences. However, *not* making those choices penalises the whole community, perhaps not as visibly: more choices leads to a greater cognitive load, a longer learning curve, a greater barrier to entry off of which many potential users will bounce. And for us compiler developers, more alternatives and combinations to consider and test for, with more surprising emergent behaviours, more bugs and more work to do.

In my view, if we want greater adoption we have to be opinionated: make difficult decisions that remove choices and streamline the language. At the very least, don't add more choices.

But to Joachim's specific question: yes I like the idea of considering the "when will it be ready?" question for each extension, to precompute the input to the GHC20xx process.

Cheers Simon

On Fri, 2 Dec 2022 at 15:06, Arnaud Spiwack mailto:arnaud.spiwack@tweag.io> wrote: I believe that I've been vocal in the past about my view that extensions should eventually become on by default. And even about the fact that I struggle to understand the point of view of extensions as configuration switches. I have no idea, however, how numerous each side of this debate is, nor how strongly the beliefs are held (very strongly in my case, obviously, but I don't know for others).

I think that you're right, Joachim, and that it's time to make a definite decision about that and make the decision one of our Principles.

If we come to the side that extensions are to eventually become defaults, I agree that the question of how to deprecate extensions that will never make it to the default is something that we have to tackle. A slightly more difficult discussion is how do we deprecate things that used to be the default. Imagine, say, that we want to make `-XMonoLocalBinds` the default, `-XMonoLocalBinds` is really removing a feature (as such it should probably be named something like `-XNoGeneralizeLocaBinds`), what does the deprecation period look like? Maybe it's actually the same question as deprecating a non-default extension, but maybe not.

On Fri, 2 Dec 2022 at 12:07, Joachim Breitner mailto:mail@joachim-breitner.de> wrote: Hello Committee and Community,

occasionally we have meta-discussions about GHC language extensions: Should they be allowed to be fork-like, where some extensions are unlikely to be used together and some stay opt-in forever? Or should (ideally) every extension be on track to become on-by-default.

Of course there are a few “old” extensions that by their very nature are not suitable to be on by default (SAFE, TRUSTWORTHY and CPP are the obvious candidates). Let’s put them aside for this discussion. I’d wager that if we’d introduce them these days, they wouldn’t be language extensions in the first place, but maybe modifiers on the module.

I am mostly in the camp “every extension should be on track to become default (or be discarded)”. Once a language feature has been proven useful and reasonable stable, I see little value in requiring programmers to jump through hoops to use them.

Is that the prevalent view here as well, or do we have a strong camp saying that our current “pick-and-choose” approach to language features is actually a good thing in its own (and not just a necessary nuisance)?

If we assume the former, then maybe it would be worth to frame the discussion around new language extensions, and the discussion about which language extensions become default, around that vision. Concretely:

* A new language proposal should not just be good enough for “worth building for those who explicitly turn it on”, but really ought convince as “this will make Haskell better for all” (and not just “a Haskell”).

* Most new language features should probably not on by default initially, as usual, and are initially experimental. But then the proposal, and if accepted the documentation of the extension, should as explicit as possible explain why it is not yet default: What needs to happen for _this_ extension to be considered ready – or judged negatively and put on a track towards removal.

This could be something like “been available for n releases, been stable for m releases”. (I wonder what other kind of criteria to expect here?)

* The process for defining GHC20xx would then become very different: We’d go through all experimental extensions, check if the criteria are satisfied, maybe apply some common sense if the criteria are still good ones, and turn it on if so.

This may turn the process to be more structured and maybe more predictable, and hopefully reduces the number of non-default extensions developers have to make a decision about (probably good). But it does raise the bar for new language features (is that good?). And, if applied consequently, it suggests to deprecate and eventually remove extensions that turn out to not be default-worthy after all (that’s kinda harsh)?

As you can see I am a bit unsure about what the criteria are that we could put in the docs. Are they really different for different extensions? But the fact that its hard to come up right now with a concrete reason why extension X is not yet the default does point to a hole in our thinking and our process!

And it is the same question that we face when discussing GHC20xx. So I guess what I am proposing here is: Have that discussion (when is it ready?) already when accepting a proposal, and document it in clear sight for our users, rather than have it over and over when debating GHC20xx.

This is not a concrete (meta-)proposal, but hopefully tasty food for thought.

Cheers, Joachim

-- Joachim Breitner mail@joachim-breitner.de mailto:mail@joachim-breitner.de http://www.joachim-breitner.de/ http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee 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

5:39 p.m.

Hi, Am Freitag, dem 02.12.2022 um 17:27 +0000 schrieb Chris Dornan:

...

I am sympathetic to the idea of a new language standard that we promote heavily and encourage developers, tools, tutorials and courseware to favour —if we get this right then we will reap the benefits of a strong standard. But if we take it upon ourselves to try and force an extension combination of our choosing on the community because we believe the community will benefit from a big reset then I think it could blow up on us really badly, with forks and factions which could be truly difficult to manage — and fatally discourage adoption.

ah, sorry if I was unclear. I am certainly not proposing a form of “big reset”! It’s more about “should every language extension be in principle on track towards in inclusion to a future GHC20xx” – still all incremental and cautious. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Chris Dornan

7:04 p.m.

I think we are on the same page, but the thread seemed to be taking an authoritarian turn so I thought it best to ensure the voices of caution were represented! Chris

...

On 2 Dec 2022, at 17:39, Joachim Breitner wrote:

Hi,

Am Freitag, dem 02.12.2022 um 17:27 +0000 schrieb Chris Dornan:

...
I am sympathetic to the idea of a new language standard that we promote heavily and encourage developers, tools, tutorials and courseware to favour —if we get this right then we will reap the benefits of a strong standard. But if we take it upon ourselves to try and force an extension combination of our choosing on the community because we believe the community will benefit from a big reset then I think it could blow up on us really badly, with forks and factions which could be truly difficult to manage — and fatally discourage adoption.

ah, sorry if I was unclear. I am certainly not proposing a form of “big reset”! It’s more about “should every language extension be in principle on track towards in inclusion to a future GHC20xx” – still all incremental and cautious.

Cheers, Joachim

-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

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

Simon Marlow

5 Dec 5 Dec

7:03 p.m.

Apologies, I didn't mean to sound like I wanted us to be "authoritarian", perhaps more along the lines of "opinionated". By analogy with the CLC: they are forced to make decisions, because there is only one set of core libraries. I don't necessarily agree with all the decisions that the CLC makes, but I'm very glad we only have one set of core libraries. In GHC we have the dubious luxury of being able to give people optional language features, I'm suggesting we should use this very carefully and avoid forks - which is our current policy anyway - but to be more intentional about it in the way that Joachim suggested. I'm also a fan of an open platform that encourages experimentation, but at some point we have to accept (I believe) that too much of this leads to a poor experience for new users. (that's putting it gently! I'm itching to rant about this some more, but I fear it may come across poorly. One for the pub.) Cheers Simon On Fri, 2 Dec 2022 at 19:04, Chris Dornan wrote:

...

I think we are on the same page, but the thread seemed to be taking an authoritarian turn so I thought it best to ensure the voices of caution were represented!

Chris

...
On 2 Dec 2022, at 17:39, Joachim Breitner wrote:

Hi,

Am Freitag, dem 02.12.2022 um 17:27 +0000 schrieb Chris Dornan:

...
I am sympathetic to the idea of a new language standard that we promote heavily and encourage developers, tools, tutorials and courseware to favour —if we get this right then we will reap the benefits of a strong standard. But if we take it upon ourselves to try and force an extension combination of our choosing on the community because we believe the community will benefit from a big reset then I think it could blow up on us really badly, with forks and factions which could be truly difficult to manage — and fatally discourage adoption.

ah, sorry if I was unclear. I am certainly not proposing a form of “big reset”! It’s more about “should every language extension be in principle on track towards in inclusion to a future GHC20xx” – still all incremental and cautious.

Cheers, Joachim

-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ 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

Chris Dornan

9:03 p.m.

Now I am sorry — my tongue was in my cheek in talking about the thread taking an authoritarian turn! I think we can al agree that there is a cost to adding more and more extensions, and bear the mounting complexity in mind when scrutinising these proposals, and try to steer this review process towards a coherent future language. At least that is my understanding of the spirit of what Joachim is getting at when he initiated this thread, in which case count me in. My point is just that we don’t also forget certain necessary messy realities in attempting to unwind ourselves from the ‘excessive’ complexity that our open, experimental philosophy/DNA will tend to generate. I would love to here more from Simon venting on what needs to happen, ideally down the pub, but, more practically, we might have to make do with a virtual one… Chris

...

On 5 Dec 2022, at 19:03, Simon Marlow wrote:

Apologies, I didn't mean to sound like I wanted us to be "authoritarian", perhaps more along the lines of "opinionated". By analogy with the CLC: they are forced to make decisions, because there is only one set of core libraries. I don't necessarily agree with all the decisions that the CLC makes, but I'm very glad we only have one set of core libraries.

In GHC we have the dubious luxury of being able to give people optional language features, I'm suggesting we should use this very carefully and avoid forks - which is our current policy anyway - but to be more intentional about it in the way that Joachim suggested. I'm also a fan of an open platform that encourages experimentation, but at some point we have to accept (I believe) that too much of this leads to a poor experience for new users. (that's putting it gently! I'm itching to rant about this some more, but I fear it may come across poorly. One for the pub.)

Cheers Simon

On Fri, 2 Dec 2022 at 19:04, Chris Dornan mailto:chris@chrisdornan.com> wrote: I think we are on the same page, but the thread seemed to be taking an authoritarian turn so I thought it best to ensure the voices of caution were represented!

Chris

...
On 2 Dec 2022, at 17:39, Joachim Breitner mailto:mail@joachim-breitner.de> wrote:

Hi,

Am Freitag, dem 02.12.2022 um 17:27 +0000 schrieb Chris Dornan:

...
I am sympathetic to the idea of a new language standard that we promote heavily and encourage developers, tools, tutorials and courseware to favour —if we get this right then we will reap the benefits of a strong standard. But if we take it upon ourselves to try and force an extension combination of our choosing on the community because we believe the community will benefit from a big reset then I think it could blow up on us really badly, with forks and factions which could be truly difficult to manage — and fatally discourage adoption.

ah, sorry if I was unclear. I am certainly not proposing a form of “big reset”! It’s more about “should every language extension be in principle on track towards in inclusion to a future GHC20xx” – still all incremental and cautious.

Cheers, Joachim

-- Joachim Breitner mail@joachim-breitner.de mailto:mail@joachim-breitner.de http://www.joachim-breitner.de/ http://www.joachim-breitner.de/

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

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

Arnaud Spiwack

8 Dec 8 Dec

5:29 p.m.

Personally, my concern is primarily procedural. There is no official stance on what an extension can be, so different people map different concepts on them. As a result, we have a lot of conversations (in here, in proposal threads) where everybody speaks past one another. What I would like is that we come together and design a principle saying: we strive for future extensions to be X. This would clarify discussions around - Is a new extension X appropriate? - Should extension X imply extension Y? - Should extension X be included in GHC20XX? My personal (strong) preference is for striving for extensions to either become a default, eventually, or to be deprecated. It also seems to be the preference of most of those who spoke up here. But what really matters is that we make a choice. The choice can be: “An extension is a switch that triggers optional behaviour in the language, it can be used to gate advanced features, some (but probably not all) of these extensions will become defaults if their use is generalised enough”, I'd disagree with the choice, but I'd champion it anyway. Note that this option is compatible with the no-language-fork principle. My point is: we need to take an explicit stance and record it. /Arnaud On Mon, 5 Dec 2022 at 22:03, Chris Dornan wrote:

...

Now I am sorry — my tongue was in my cheek in talking about the thread taking an authoritarian turn!

I think we can al agree that there is a cost to adding more and more extensions, and bear the mounting complexity in mind when scrutinising these proposals, and try to steer this review process towards a coherent future language. At least that is my understanding of the spirit of what Joachim is getting at when he initiated this thread, in which case count me in. My point is just that we don’t also forget certain necessary messy realities in attempting to unwind ourselves from the ‘excessive’ complexity that our open, experimental philosophy/DNA will tend to generate.

I would love to here more from Simon venting on what needs to happen, ideally down the pub, but, more practically, we might have to make do with a virtual one…

Chris

On 5 Dec 2022, at 19:03, Simon Marlow wrote:

Apologies, I didn't mean to sound like I wanted us to be "authoritarian", perhaps more along the lines of "opinionated". By analogy with the CLC: they are forced to make decisions, because there is only one set of core libraries. I don't necessarily agree with all the decisions that the CLC makes, but I'm very glad we only have one set of core libraries.

In GHC we have the dubious luxury of being able to give people optional language features, I'm suggesting we should use this very carefully and avoid forks - which is our current policy anyway - but to be more intentional about it in the way that Joachim suggested. I'm also a fan of an open platform that encourages experimentation, but at some point we have to accept (I believe) that too much of this leads to a poor experience for new users. (that's putting it gently! I'm itching to rant about this some more, but I fear it may come across poorly. One for the pub.)

Cheers Simon

On Fri, 2 Dec 2022 at 19:04, Chris Dornan wrote:

...
I think we are on the same page, but the thread seemed to be taking an authoritarian turn so I thought it best to ensure the voices of caution were represented!

Chris

...
On 2 Dec 2022, at 17:39, Joachim Breitner wrote:

Hi,

Am Freitag, dem 02.12.2022 um 17:27 +0000 schrieb Chris Dornan:

...
I am sympathetic to the idea of a new language standard that we promote heavily and encourage developers, tools, tutorials and courseware to favour —if we get this right then we will reap the benefits of a strong standard. But if we take it upon ourselves to try and force an extension combination of our choosing on the community because we believe the community will benefit from a big reset then I think it could blow up on us really badly, with forks and factions which could be truly difficult to manage — and fatally discourage adoption.

ah, sorry if I was unclear. I am certainly not proposing a form of “big reset”! It’s more about “should every language extension be in principle on track towards in inclusion to a future GHC20xx” – still all incremental and cautious.

Cheers, Joachim

-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ 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

Simon Peyton Jones

5:53 p.m.

...

The choice can be:... My point is: we need to take an explicit stance and record it.

Do you want to lay out * the problem you want to solve * a set of possible choices that might solve it Personally I don't perceive an immediate problem that we need to solve. But I'm an outlier and willing to be educated. On Thu, 8 Dec 2022 at 17:30, Arnaud Spiwack wrote:

...

Personally, my concern is primarily procedural. There is no official stance on what an extension can be, so different people map different concepts on them. As a result, we have a lot of conversations (in here, in proposal threads) where everybody speaks past one another. What I would like is that we come together and design a principle saying: we strive for future extensions to be X. This would clarify discussions around - Is a new extension X appropriate? - Should extension X imply extension Y? - Should extension X be included in GHC20XX?

My personal (strong) preference is for striving for extensions to either become a default, eventually, or to be deprecated. It also seems to be the preference of most of those who spoke up here. But what really matters is that we make a choice. The choice can be: “An extension is a switch that triggers optional behaviour in the language, it can be used to gate advanced features, some (but probably not all) of these extensions will become defaults if their use is generalised enough”, I'd disagree with the choice, but I'd champion it anyway. Note that this option is compatible with the no-language-fork principle.

My point is: we need to take an explicit stance and record it.

/Arnaud

On Mon, 5 Dec 2022 at 22:03, Chris Dornan wrote:

...
Now I am sorry — my tongue was in my cheek in talking about the thread taking an authoritarian turn!

I think we can al agree that there is a cost to adding more and more extensions, and bear the mounting complexity in mind when scrutinising these proposals, and try to steer this review process towards a coherent future language. At least that is my understanding of the spirit of what Joachim is getting at when he initiated this thread, in which case count me in. My point is just that we don’t also forget certain necessary messy realities in attempting to unwind ourselves from the ‘excessive’ complexity that our open, experimental philosophy/DNA will tend to generate.

I would love to here more from Simon venting on what needs to happen, ideally down the pub, but, more practically, we might have to make do with a virtual one…

Chris

On 5 Dec 2022, at 19:03, Simon Marlow wrote:

Apologies, I didn't mean to sound like I wanted us to be "authoritarian", perhaps more along the lines of "opinionated". By analogy with the CLC: they are forced to make decisions, because there is only one set of core libraries. I don't necessarily agree with all the decisions that the CLC makes, but I'm very glad we only have one set of core libraries.

In GHC we have the dubious luxury of being able to give people optional language features, I'm suggesting we should use this very carefully and avoid forks - which is our current policy anyway - but to be more intentional about it in the way that Joachim suggested. I'm also a fan of an open platform that encourages experimentation, but at some point we have to accept (I believe) that too much of this leads to a poor experience for new users. (that's putting it gently! I'm itching to rant about this some more, but I fear it may come across poorly. One for the pub.)

Cheers Simon

On Fri, 2 Dec 2022 at 19:04, Chris Dornan wrote:

...
I think we are on the same page, but the thread seemed to be taking an authoritarian turn so I thought it best to ensure the voices of caution were represented!

Chris

...
On 2 Dec 2022, at 17:39, Joachim Breitner wrote:

Hi,

Am Freitag, dem 02.12.2022 um 17:27 +0000 schrieb Chris Dornan:

...
I am sympathetic to the idea of a new language standard that we promote heavily and encourage developers, tools, tutorials and courseware to favour —if we get this right then we will reap the benefits of a strong standard. But if we take it upon ourselves to try and force an extension combination of our choosing on the community because we believe the community will benefit from a big reset then I think it could blow up on us really badly, with forks and factions which could be truly difficult to manage — and fatally discourage adoption.

ah, sorry if I was unclear. I am certainly not proposing a form of “big reset”! It’s more about “should every language extension be in principle on track towards in inclusion to a future GHC20xx” – still all incremental and cautious.

Cheers, Joachim

-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ 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

Adam Gundry

9 Dec 9 Dec

10:44 a.m.

I'm not convinced we should strive to eliminate all extensions as either "successful" (part of the default language), or "failed" experiments (deprecated and perhaps eventually removed). While it is surely good to reduce the proliferation of extensions that can itself be a source of confusion, there are still benefits to distinguishing "language levels". The right choice of language features can be context dependent, and invoking more powerful features is always a trade-off, so I think it is a positive virtue that LANGUAGE pragmas let us pass that choice to users/codebases. AntC made a good comment to this effect at https://github.com/ghc-proposals/ghc-proposals/pull/559#issuecomment-1336059.... By all means let's reduce the number of trivial syntactic extensions that exist primarily for backwards compatibility purposes. But for semantically meaningful extensions, I would rather make the ability to choose language features even more local, so that a user can tightly constrain their use to where they are needed, for example: module M where -- I would like GHC to complain if I accidentally risk compile time -- non-termination with this instance... instance ... => Foo T -- but for this one I need to lift the check, and have accepted the -- corresponding responsibility to ensure the instance is sensible. language UndecidableInstances where instance ... => Bar T Cheers, Adam On 08/12/2022 17:53, Simon Peyton Jones wrote:

...

The choice can be:... My point is: we need to take an explicit stance and record it.

Do you want to lay out * the problem you want to solve * a set of possible choices that might solve it

Personally I don't perceive an immediate problem that we need to solve. But I'm an outlier and willing to be educated.

On Thu, 8 Dec 2022 at 17:30, Arnaud Spiwack mailto:arnaud.spiwack@tweag.io> wrote:

Personally, my concern is primarily procedural. There is no official stance on what an extension can be, so different people map different concepts on them. As a result, we have a lot of conversations (in here, in proposal threads) where everybody speaks past one another. What I would like is that we come together and design a principle saying: we strive for future extensions to be X. This would clarify discussions around - Is a new extension X appropriate? - Should extension X imply extension Y? - Should extension X be included in GHC20XX?

My personal (strong) preference is for striving for extensions to either become a default, eventually, or to be deprecated. It also seems to be the preference of most of those who spoke up here. But what really matters is that we make a choice. The choice can be: “An extension is a switch that triggers optional behaviour in the language, it can be used to gate advanced features, some (but probably not all) of these extensions will become defaults if their use is generalised enough”, I'd disagree with the choice, but I'd champion it anyway. Note that this option is compatible with the no-language-fork principle.

My point is: we need to take an explicit stance and record it.

/Arnaud

On Mon, 5 Dec 2022 at 22:03, Chris Dornan mailto:chris@chrisdornan.com> wrote:

Now I am sorry — my tongue was in my cheek in talking about the thread taking an authoritarian turn!

I think we can al agree that there is a cost to adding more and more extensions, and bear the mounting complexity in mind when scrutinising these proposals, and try to steer this review process towards a coherent future language. At least that is my understanding of the spirit of what Joachim is getting at when he initiated this thread, in which case count me in. My point is just that we don’t also forget certain necessary messy realities in attempting to unwind ourselves from the ‘excessive’ complexity that our open, experimental philosophy/DNA will tend to generate.

I would love to here more from Simon venting on what needs to happen, ideally down the pub, but, more practically, we might have to make do with a virtual one…

Chris

...
On 5 Dec 2022, at 19:03, Simon Marlow mailto:marlowsd@gmail.com> wrote:

Apologies, I didn't mean to sound like I wanted us to be "authoritarian", perhaps more along the lines of "opinionated". By analogy with the CLC: they are forced to make decisions, because there is only one set of core libraries. I don't necessarily agree with all the decisions that the CLC makes, but I'm very glad we only have one set of core libraries.

In GHC we have the dubious luxury of being able to give people optional language features, I'm suggesting we should use this very carefully and avoid forks - which is our current policy anyway - but to be more intentional about it in the way that Joachim suggested. I'm also a fan of an open platform that encourages experimentation, but at some point we have to accept (I believe) that too much of this leads to a poor experience for new users. (that's putting it gently! I'm itching to rant about this some more, but I fear it may come across poorly. One for the pub.)

Cheers Simon

On Fri, 2 Dec 2022 at 19:04, Chris Dornan mailto:chris@chrisdornan.com> wrote:

I think we are on the same page, but the thread seemed to be taking an authoritarian turn so I thought it best to ensure the voices of caution were represented!

Chris

> On 2 Dec 2022, at 17:39, Joachim Breitner mailto:mail@joachim-breitner.de> wrote: > > Hi, > > Am Freitag, dem 02.12.2022 um 17:27 +0000 schrieb Chris Dornan: >> I am sympathetic to the idea of a new language standard that we >> promote heavily and encourage developers, tools, tutorials and >> courseware to favour —if we get this right then we will reap the >> benefits of a strong standard. But if we take it upon ourselves to >> try and force an extension combination of our choosing on the >> community because we believe the community will benefit from a big >> reset then I think it could blow up on us really badly, with forks >> and factions which could be truly difficult to manage — and fatally >> discourage adoption. > > ah, sorry if I was unclear. I am certainly not proposing a form of “big > reset”! It’s more about “should every language extension be in > principle on track towards in inclusion to a future GHC20xx” – still > all incremental and cautious. > > Cheers, > Joachim

-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England

Richard Eisenberg

2:21 p.m.

I have divided this email into two parts. The first part presents what are my observations of this (and related) conversation. Then I share my opinion in the second part.

...

On Dec 8, 2022, at 12:53 PM, Simon Peyton Jones wrote:

* the problem you want to solve

We, as a committee, struggle to figure out a policy around extensions. This policy would help inform decisions such as: * whether proposal X needs to come with an extension, can modify a previous one, or needs no extension at all * how to evolve the set of extensions that are part of GHC20XX / the default set of extensions Beyond these real-world challenges that the committee has faced, we might also want to consider * how better to communicate the role extensions play in the Haskell language (anecdotes suggest the current story is off-putting to newcomers) * whether some extensions ought to be retired While all decisions would continue to be made on a case-by-case basis, discussions in the past have suggested that individual members have very different criteria for making these calls, stymieing effective debate. Thus the problem is that we, the committee, don't have common goals for the extensions feature of the language. Accordingly, our decisions in this space easily risk being incoherent, which is a problem.

...

* a set of possible choices that might solve it

I spot several solutions drawn from our conversations: 1. Declare that extensions are experimental language features, being evaluated for inclusion in the language proper. Gating some new syntax behind an extension theoretically allows us to experiment, improve, etc., until we are happy, and then we merge the feature into the language, with no extension needed. 2. Declare that extensions are configuration flags, meant to exist in perpetuity. In this way, extensions are a more powerful form of warning flag: not only can they dictate which programs are accepted, but sometimes they can be used to change the semantics of an accepted program. 3. Organize the set of extensions around an idea of language levels, where we classify different extensions according to the expected level of expertise of users working in the extended language. The levels themselves would exist in perpetuity, but the extensions themselves may eventually just be folded into the choice of language level. This is something of a hybrid between (1) and (2). Perhaps others have other ideas, but I hope I've captured the different approaches floated so far. Given the fact that we're working in an existing language, we have to incorporate the reality of today's Haskell: some existing language extensions are unmistakably configuration flags (e.g. RebindableSyntax, Safe) which could never reasonably be on by default. I urge us not to get caught on these snags. Once we have a general approach, we can come back to these if necessary and see how to incorporate them. ------------------------- I used to be in Camp 2, thinking that extensions make for good configuration flags, and would exist in perpetuity -- or at least until a standards committee forms and writes the next version of the standard. I've now switched over to Camp 1. The extensions system continues to grow without seeming bound. This fragments our community somewhat (think of the various exhortations to only use these extensions), provides a source of unnecessary and bureaucratic complexity to users, and means that language maintainers must consider 2^n languages. (When I last counted, n was around 150. It may have grown since.) What does it even mean that a language has a core and has extensions? We could argue that the unextended language is Haskell2010, but I don't think that's a useful designation in 2022. So why have the distinction between a core and an extension? I'm honestly not sure what the value is there. And I think the current state of this actively harms the language. Glancing through the list of extensions, I see a few broad categories: A. Extensions that simply enable new syntax. If users still want fine control over whether this syntax is allowed, each such extension could be converted to a warning -- but then all these extensions (except ones that are still experimental!) would be on by default. Maybe the warnings would be -Werror by default -- not sure. Examples: GADTSyntax, Arrows, InstanceSigs, StandaloneDeriving, and many more. B. Extensions that allow violation of some general principle that holds elsewhere. These should be replaced by modifiers or pragmas and be enabled locally. Examples: OverlappingInstances (this is already done!), NoMonomorphismRestriction, DeepSubsumption(*), UndecidableSuperClasses, NoMonoLocalBinds, etc. (*): Given the hue and cry about this one, perhaps there should be a flag to control the behavior. C. Extensions that change the compilation pipeline. These need to remain as configuration flags. Examples: CPP, TemplateHaskell. D. Extensions that create variants of the language by changing semantics of existing constructs. I'm not quite sure what to do with these, but they probably need to remain configuration flags. Even better if they could be enabled locally within a file, though. We should probably try to avoid doing this in the future, though the pain may be worth it. Examples: RebindableSyntax, Strict, OverloadedXXX, etc. Maybe some extensions fail to be categorized here, but this covers the vast, vast majority. About language levels: I like the idea of language levels. But I would want them to be mostly about error messages, not about gating language features. That is, at level 1, `x :: Just Int` wouldn't get "Did you want to turn on DataKinds?" but instead a message about confusing types and terms. So it's possible to do the language-level idea without hooking it to extensions. I think. Richard

Joachim Breitner

6:57 p.m.

Hi, this categorization is very helpful, I’ve been thinking about that as well recently. Especially it’s worth keeping in mind that some language extensions probably wouldn’t be language extensions these days, but some other kind of flag (CPP, Safe, Trustworthy), and as you say shouldn’t get in the way of finding a more coherent story for the others. I think we should keep separate the category F: Enables new language features with not just a local (usually) syntactic effect. (Litmus test: will a user of a module with that extension tell). Mostly all the type-level feature extension (GADTs, LinearTypes, TypeFamilies etc.) Some of these are also guarded by “new syntax” of sorts, but I think they are fundamentally different from your category A. These are, in a way, the most interesting ones! Cheers, Joachim Am Freitag, dem 09.12.2022 um 14:21 +0000 schrieb Richard Eisenberg:

...

Glancing through the list of extensions, I see a few broad categories:

A. Extensions that simply enable new syntax. If users still want fine control over whether this syntax is allowed, each such extension could be converted to a warning -- but then all these extensions (except ones that are still experimental!) would be on by default. Maybe the warnings would be -Werror by default -- not sure. Examples: GADTSyntax, Arrows, InstanceSigs, StandaloneDeriving, and many more.

B. Extensions that allow violation of some general principle that holds elsewhere. These should be replaced by modifiers or pragmas and be enabled locally. Examples: OverlappingInstances (this is already done!), NoMonomorphismRestriction, DeepSubsumption(*), UndecidableSuperClasses, NoMonoLocalBinds, etc.

(*): Given the hue and cry about this one, perhaps there should be a flag to control the behavior.

C. Extensions that change the compilation pipeline. These need to remain as configuration flags. Examples: CPP, TemplateHaskell.

D. Extensions that create variants of the language by changing semantics of existing constructs. I'm not quite sure what to do with these, but they probably need to remain configuration flags. Even better if they could be enabled locally within a file, though. We should probably try to avoid doing this in the future, though the pain may be worth it. Examples: RebindableSyntax, Strict, OverloadedXXX, etc.

Maybe some extensions fail to be categorized here, but this covers the vast, vast majority.

-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Arnaud Spiwack

13 Dec 13 Dec

9:42 a.m.

Thanks Richard for answering more comprehensively than I could have done myself. Simon: do you feel that Richard's email answers your question? On Fri, 9 Dec 2022 at 19:57, Joachim Breitner wrote:

...

Hi,

this categorization is very helpful, I’ve been thinking about that as well recently. Especially it’s worth keeping in mind that some language extensions probably wouldn’t be language extensions these days, but some other kind of flag (CPP, Safe, Trustworthy), and as you say shouldn’t get in the way of finding a more coherent story for the others.

I think we should keep separate the category

F: Enables new language features with not just a local (usually) syntactic effect. (Litmus test: will a user of a module with that extension tell). Mostly all the type-level feature extension (GADTs, LinearTypes, TypeFamilies etc.)

Some of these are also guarded by “new syntax” of sorts, but I think they are fundamentally different from your category A. These are, in a way, the most interesting ones!

Cheers, Joachim

Am Freitag, dem 09.12.2022 um 14:21 +0000 schrieb Richard Eisenberg:

...
Glancing through the list of extensions, I see a few broad categories:

A. Extensions that simply enable new syntax. If users still want fine control over whether this syntax is allowed, each such extension could be converted to a warning -- but then all these extensions (except ones that are still experimental!) would be on by default. Maybe the warnings would be -Werror by default -- not sure. Examples: GADTSyntax, Arrows, InstanceSigs, StandaloneDeriving, and many more.

B. Extensions that allow violation of some general principle that holds elsewhere. These should be replaced by modifiers or pragmas and be enabled locally. Examples: OverlappingInstances (this is already done!), NoMonomorphismRestriction, DeepSubsumption(*), UndecidableSuperClasses, NoMonoLocalBinds, etc.

(*): Given the hue and cry about this one, perhaps there should be a flag to control the behavior.

C. Extensions that change the compilation pipeline. These need to remain as configuration flags. Examples: CPP, TemplateHaskell.

D. Extensions that create variants of the language by changing semantics of existing constructs. I'm not quite sure what to do with these, but they probably need to remain configuration flags. Even better if they could be enabled locally within a file, though. We should probably try to avoid doing this in the future, though the pain may be worth it. Examples: RebindableSyntax, Strict, OverloadedXXX, etc.

Maybe some extensions fail to be categorized here, but this covers the vast, vast majority.

-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

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

Simon Peyton Jones

9:59 a.m.

...

Thanks Richard for answering more comprehensively than I could have done myself. Simon: do you feel that Richard's email answers your question?

It contributes to an answer. *The problem(s) we seek to solve* Richard says We, as a committee, struggle to figure out a policy around extensions. This policy would help inform decisions such as: * whether proposal X needs to come with an extension, can modify a previous one, or needs no extension at all * how to evolve the set of extensions that are part of GHC20XX / the default set of extensions Beyond these real-world challenges that the committee has faced, we might also want to consider * how better to communicate the role extensions play in the Haskell language (anecdotes suggest the current story is off-putting to newcomers) * whether some extensions ought to be retired I'm OK with those as goals, although I have not found myself stuck on them. E.g. most proposals do come with an extension because they are, well, an extension. And user opinions frankly differ about the value and tempo of GHC20XX. *The proposed solution(s)* Richard comes up with a couple of categorisations, which are indeed helpful. But he stops short of any concrete proposals. 1. Declare that extensions are *experimental language features*, being evaluated for inclusion in the language proper. Gating some new syntax behind an extension theoretically allows us to experiment, improve, etc., until we are happy, and then we merge the feature into the language, with no extension needed. 2. Declare that extensions are *configuration flags*, meant to exist in perpetuity. In this way, extensions are a more powerful form of warning flag: not only can they dictate which programs are accepted, but sometimes they can be used to change the semantics of an accepted program. 3. Organize the set of extensions around an idea of *language levels*, where we classify different extensions according to the expected level of expertise of users working in the extended language. These aren't either/or choices. It's clear that - some really are configuration flags (Safe, RebindableSyntax; maybe punning) - some are definitely local, thin ice (UndecidableSuperclasses) -- the more we can turn these into local modifiers the better - some are really part of the language we'd like to see (PolyKinds, MultiParamTypeClasses) - some are experimental in the "Haskell as a laboratory" sense (Linear) I think that *classifying *them might be helpful; *choosing one *of these paths over the others seems infeasible to me. *What next?* I suppose the next step is for some motivated person to write a draft policy paper, so we can say "This is the GHC steering committee's policy on extensions". Maybe it too can be a GHC proposal (rather like the design principles one). It can certainly include the categorisations Richard suggests. Simon On Tue, 13 Dec 2022 at 09:43, Arnaud Spiwack wrote:

...

Thanks Richard for answering more comprehensively than I could have done myself. Simon: do you feel that Richard's email answers your question?

On Fri, 9 Dec 2022 at 19:57, Joachim Breitner wrote:

...
Hi,

this categorization is very helpful, I’ve been thinking about that as well recently. Especially it’s worth keeping in mind that some language extensions probably wouldn’t be language extensions these days, but some other kind of flag (CPP, Safe, Trustworthy), and as you say shouldn’t get in the way of finding a more coherent story for the others.

I think we should keep separate the category

F: Enables new language features with not just a local (usually) syntactic effect. (Litmus test: will a user of a module with that extension tell). Mostly all the type-level feature extension (GADTs, LinearTypes, TypeFamilies etc.)

Some of these are also guarded by “new syntax” of sorts, but I think they are fundamentally different from your category A. These are, in a way, the most interesting ones!

Cheers, Joachim

Am Freitag, dem 09.12.2022 um 14:21 +0000 schrieb Richard Eisenberg:

...
Glancing through the list of extensions, I see a few broad categories:

A. Extensions that simply enable new syntax. If users still want fine control over whether this syntax is allowed, each such extension could be converted to a warning -- but then all these extensions (except ones that are still experimental!) would be on by default. Maybe the warnings would be -Werror by default -- not sure. Examples: GADTSyntax, Arrows, InstanceSigs, StandaloneDeriving, and many more.

B. Extensions that allow violation of some general principle that holds elsewhere. These should be replaced by modifiers or pragmas and be enabled locally. Examples: OverlappingInstances (this is already done!), NoMonomorphismRestriction, DeepSubsumption(*), UndecidableSuperClasses, NoMonoLocalBinds, etc.

(*): Given the hue and cry about this one, perhaps there should be a flag to control the behavior.

C. Extensions that change the compilation pipeline. These need to remain as configuration flags. Examples: CPP, TemplateHaskell.

D. Extensions that create variants of the language by changing semantics of existing constructs. I'm not quite sure what to do with these, but they probably need to remain configuration flags. Even better if they could be enabled locally within a file, though. We should probably try to avoid doing this in the future, though the pain may be worth it. Examples: RebindableSyntax, Strict, OverloadedXXX, etc.

Maybe some extensions fail to be categorized here, but this covers the vast, vast majority.

-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ 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

Chris Dornan

5:08 p.m.

It is very fashionable to dunk on GHC language extensions but I think it is worth considering where we would be without them — probably Haskell 98 and a nice Wikipedia page explaining how influential Haskell was — a remarkable academic experiment, but practically speaking, like FP and KRC and Hope, a dead programming language. I had a period in the late naughties away from Haskell and I thought it was great to be able to work with the familiar Haskell 98 and page in the developments as I needed them, and easily locate documentation, papers and articles on those proposals. The modularity that extensions provide is a real practical strength that is often overlooked. Further to that, I find it quite difficult to get my head around the sheer vitality of Haskell today. It was tempting to conclude that Haskell2010 would be the last harrah but building Haskell code bases in 2022 is really quite different and a *much* more rewarding and more productive exercise in my opinion, thanks to generics and the ingenious exploration of newtype, especially with DerivingVia. This is really quite separate from all the work on TLP and DH — I am talking about the very practical business of building, organising and maintaining non-trivial Haskell code bases. I love the way we have become keen to learn from other successes like Rust but I fear we could repeat past mistakes in a dash to force Haskell, and the Haskell community, into a particular shape so that it can compete. I think we should have more confidence in what has got us to where we are — and there is no doubt in my mind that it is the enduring vitality of Haskell that flows from its open philosophy, open to allcomers and open to creative experimentation. I think the intrinsic diversity we see at all levels of the community is important to that creative process which is why I get a little despondent when I see calls to eliminate that diversity. People see the language extensions in different ways depending on the problems they are trying to solve and those problems are arising in great array of different contexts — and that feeds vitality is what keeps us moving forward (like the proverbial shark). I understand that we can’t just allow ourselves to suffer a chaotic heat death and we need a continuous effort to analyse and organise, but I look at the diversity of thought and approaches and see the basis of a vibrant future. I just ask that we seek to organise and not to develop a monoculture. Which is all by way of saying that I think the diversity we see in the extensions and the different ways of understanding them as important to the whole enterprise and take care with any drives to rationalise them into a more coherent structure. Chris

...

On 13 Dec 2022, at 09:59, Simon Peyton Jones wrote:

Thanks Richard for answering more comprehensively than I could have done myself. Simon: do you feel that Richard's email answers your question?

It contributes to an answer.

The problem(s) we seek to solve

Richard says

We, as a committee, struggle to figure out a policy around extensions. This policy would help inform decisions such as: * whether proposal X needs to come with an extension, can modify a previous one, or needs no extension at all * how to evolve the set of extensions that are part of GHC20XX / the default set of extensions Beyond these real-world challenges that the committee has faced, we might also want to consider * how better to communicate the role extensions play in the Haskell language (anecdotes suggest the current story is off-putting to newcomers) * whether some extensions ought to be retired

I'm OK with those as goals, although I have not found myself stuck on them. E.g. most proposals do come with an extension because they are, well, an extension. And user opinions frankly differ about the value and tempo of GHC20XX.

The proposed solution(s)

Richard comes up with a couple of categorisations, which are indeed helpful. But he stops short of any concrete proposals.

1. Declare that extensions are experimental language features, being evaluated for inclusion in the language proper. Gating some new syntax behind an extension theoretically allows us to experiment, improve, etc., until we are happy, and then we merge the feature into the language, with no extension needed. 2. Declare that extensions are configuration flags, meant to exist in perpetuity. In this way, extensions are a more powerful form of warning flag: not only can they dictate which programs are accepted, but sometimes they can be used to change the semantics of an accepted program. 3. Organize the set of extensions around an idea of language levels, where we classify different extensions according to the expected level of expertise of users working in the extended language.

These aren't either/or choices. It's clear that some really are configuration flags (Safe, RebindableSyntax; maybe punning) some are definitely local, thin ice (UndecidableSuperclasses) -- the more we can turn these into local modifiers the better some are really part of the language we'd like to see (PolyKinds, MultiParamTypeClasses) some are experimental in the "Haskell as a laboratory" sense (Linear) I think that classifying them might be helpful; choosing one of these paths over the others seems infeasible to me.

What next?

I suppose the next step is for some motivated person to write a draft policy paper, so we can say "This is the GHC steering committee's policy on extensions". Maybe it too can be a GHC proposal (rather like the design principles one). It can certainly include the categorisations Richard suggests.

Simon

On Tue, 13 Dec 2022 at 09:43, Arnaud Spiwack mailto:arnaud.spiwack@tweag.io> wrote: Thanks Richard for answering more comprehensively than I could have done myself. Simon: do you feel that Richard's email answers your question?

On Fri, 9 Dec 2022 at 19:57, Joachim Breitner mailto:mail@joachim-breitner.de> wrote: Hi,

this categorization is very helpful, I’ve been thinking about that as well recently. Especially it’s worth keeping in mind that some language extensions probably wouldn’t be language extensions these days, but some other kind of flag (CPP, Safe, Trustworthy), and as you say shouldn’t get in the way of finding a more coherent story for the others.

I think we should keep separate the category

F: Enables new language features with not just a local (usually) syntactic effect. (Litmus test: will a user of a module with that extension tell). Mostly all the type-level feature extension (GADTs, LinearTypes, TypeFamilies etc.)

Some of these are also guarded by “new syntax” of sorts, but I think they are fundamentally different from your category A. These are, in a way, the most interesting ones!

Cheers, Joachim

Am Freitag, dem 09.12.2022 um 14:21 +0000 schrieb Richard Eisenberg:

...
Glancing through the list of extensions, I see a few broad categories:

A. Extensions that simply enable new syntax. If users still want fine control over whether this syntax is allowed, each such extension could be converted to a warning -- but then all these extensions (except ones that are still experimental!) would be on by default. Maybe the warnings would be -Werror by default -- not sure. Examples: GADTSyntax, Arrows, InstanceSigs, StandaloneDeriving, and many more.

B. Extensions that allow violation of some general principle that holds elsewhere. These should be replaced by modifiers or pragmas and be enabled locally. Examples: OverlappingInstances (this is already done!), NoMonomorphismRestriction, DeepSubsumption(*), UndecidableSuperClasses, NoMonoLocalBinds, etc.

(*): Given the hue and cry about this one, perhaps there should be a flag to control the behavior.

C. Extensions that change the compilation pipeline. These need to remain as configuration flags. Examples: CPP, TemplateHaskell.

D. Extensions that create variants of the language by changing semantics of existing constructs. I'm not quite sure what to do with these, but they probably need to remain configuration flags. Even better if they could be enabled locally within a file, though. We should probably try to avoid doing this in the future, though the pain may be worth it. Examples: RebindableSyntax, Strict, OverloadedXXX, etc.

Maybe some extensions fail to be categorized here, but this covers the vast, vast majority.

-- Joachim Breitner mail@joachim-breitner.de mailto:mail@joachim-breitner.de http://www.joachim-breitner.de/ http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee 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

Simon Peyton Jones

5:47 p.m.

...

there is no doubt in my mind that it is the enduring vitality of Haskell that flows from its open philosophy, open to allcomers and open to creative experimentation.

Strong +1 Simon On Tue, 13 Dec 2022 at 17:09, Chris Dornan wrote:

...

It is very fashionable to dunk on GHC language extensions but I think it is worth considering where we would be without them — probably Haskell 98 and a nice Wikipedia page explaining how influential Haskell was — a remarkable academic experiment, but practically speaking, like FP and KRC and Hope, a dead programming language.

I had a period in the late naughties away from Haskell and I thought it was great to be able to work with the familiar Haskell 98 and page in the developments as I needed them, and easily locate documentation, papers and articles on those proposals. The modularity that extensions provide is a real practical strength that is often overlooked.

Further to that, I find it quite difficult to get my head around the sheer vitality of Haskell today. It was tempting to conclude that Haskell2010 would be the last harrah but building Haskell code bases in 2022 is really quite different and a *much* more rewarding and more productive exercise in my opinion, thanks to generics and the ingenious exploration of newtype, especially with DerivingVia. This is really quite separate from all the work on TLP and DH — I am talking about the very practical business of building, organising and maintaining non-trivial Haskell code bases.

I love the way we have become keen to learn from other successes like Rust but I fear we could repeat past mistakes in a dash to force Haskell, and the Haskell community, into a particular shape so that it can compete. I think we should have more confidence in what has got us to where we are — and there is no doubt in my mind that it is the enduring vitality of Haskell that flows from its open philosophy, open to allcomers and open to creative experimentation.

I think the intrinsic diversity we see at all levels of the community is important to that creative process which is why I get a little despondent when I see calls to eliminate that diversity. People see the language extensions in different ways depending on the problems they are trying to solve and those problems are arising in great array of different contexts — and that feeds vitality is what keeps us moving forward (like the proverbial shark).

I understand that we can’t just allow ourselves to suffer a chaotic heat death and we need a continuous effort to analyse and organise, but I look at the diversity of thought and approaches and see the basis of a vibrant future. I just ask that we seek to organise and not to develop a monoculture.

Which is all by way of saying that I think the diversity we see in the extensions and the different ways of understanding them as important to the whole enterprise and take care with any drives to rationalise them into a more coherent structure.

Chris

On 13 Dec 2022, at 09:59, Simon Peyton Jones wrote:

Thanks Richard for answering more comprehensively than I could have done

...
myself. Simon: do you feel that Richard's email answers your question?

It contributes to an answer.

*The problem(s) we seek to solve*

Richard says

We, as a committee, struggle to figure out a policy around extensions. This policy would help inform decisions such as: * whether proposal X needs to come with an extension, can modify a previous one, or needs no extension at all * how to evolve the set of extensions that are part of GHC20XX / the default set of extensions Beyond these real-world challenges that the committee has faced, we might also want to consider * how better to communicate the role extensions play in the Haskell language (anecdotes suggest the current story is off-putting to newcomers) * whether some extensions ought to be retired

I'm OK with those as goals, although I have not found myself stuck on them. E.g. most proposals do come with an extension because they are, well, an extension. And user opinions frankly differ about the value and tempo of GHC20XX.

*The proposed solution(s)*

Richard comes up with a couple of categorisations, which are indeed helpful. But he stops short of any concrete proposals.

1. Declare that extensions are *experimental language features*, being evaluated for inclusion in the language proper. Gating some new syntax behind an extension theoretically allows us to experiment, improve, etc., until we are happy, and then we merge the feature into the language, with no extension needed. 2. Declare that extensions are *configuration flags*, meant to exist in perpetuity. In this way, extensions are a more powerful form of warning flag: not only can they dictate which programs are accepted, but sometimes they can be used to change the semantics of an accepted program. 3. Organize the set of extensions around an idea of *language levels*, where we classify different extensions according to the expected level of expertise of users working in the extended language.

These aren't either/or choices. It's clear that

- some really are configuration flags (Safe, RebindableSyntax; maybe punning) - some are definitely local, thin ice (UndecidableSuperclasses) -- the more we can turn these into local modifiers the better - some are really part of the language we'd like to see (PolyKinds, MultiParamTypeClasses) - some are experimental in the "Haskell as a laboratory" sense (Linear)

I think that *classifying *them might be helpful; *choosing one *of these paths over the others seems infeasible to me.

*What next?*

I suppose the next step is for some motivated person to write a draft policy paper, so we can say "This is the GHC steering committee's policy on extensions". Maybe it too can be a GHC proposal (rather like the design principles one). It can certainly include the categorisations Richard suggests.

Simon

On Tue, 13 Dec 2022 at 09:43, Arnaud Spiwack wrote:

...
Thanks Richard for answering more comprehensively than I could have done myself. Simon: do you feel that Richard's email answers your question?

On Fri, 9 Dec 2022 at 19:57, Joachim Breitner wrote:

...
Hi,

this categorization is very helpful, I’ve been thinking about that as well recently. Especially it’s worth keeping in mind that some language extensions probably wouldn’t be language extensions these days, but some other kind of flag (CPP, Safe, Trustworthy), and as you say shouldn’t get in the way of finding a more coherent story for the others.

I think we should keep separate the category

F: Enables new language features with not just a local (usually) syntactic effect. (Litmus test: will a user of a module with that extension tell). Mostly all the type-level feature extension (GADTs, LinearTypes, TypeFamilies etc.)

Some of these are also guarded by “new syntax” of sorts, but I think they are fundamentally different from your category A. These are, in a way, the most interesting ones!

Cheers, Joachim

Am Freitag, dem 09.12.2022 um 14:21 +0000 schrieb Richard Eisenberg:

...
Glancing through the list of extensions, I see a few broad categories:

A. Extensions that simply enable new syntax. If users still want fine control over whether this syntax is allowed, each such extension could be converted to a warning -- but then all these extensions (except ones that are still experimental!) would be on by default. Maybe the warnings would be -Werror by default -- not sure. Examples: GADTSyntax, Arrows, InstanceSigs, StandaloneDeriving, and many more.

B. Extensions that allow violation of some general principle that holds elsewhere. These should be replaced by modifiers or pragmas and be enabled locally. Examples: OverlappingInstances (this is already done!), NoMonomorphismRestriction, DeepSubsumption(*), UndecidableSuperClasses, NoMonoLocalBinds, etc.

(*): Given the hue and cry about this one, perhaps there should be a flag to control the behavior.

C. Extensions that change the compilation pipeline. These need to remain as configuration flags. Examples: CPP, TemplateHaskell.

D. Extensions that create variants of the language by changing semantics of existing constructs. I'm not quite sure what to do with these, but they probably need to remain configuration flags. Even better if they could be enabled locally within a file, though. We should probably try to avoid doing this in the future, though the pain may be worth it. Examples: RebindableSyntax, Strict, OverloadedXXX, etc.

Maybe some extensions fail to be categorized here, but this covers the vast, vast majority.

-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ 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

Simon Marlow

14 Dec 14 Dec

11:05 a.m.

Yes, thankyou Richard! I agree with virtually everything.

...

B. Extensions that allow violation of some general principle that holds elsewhere. These should be replaced by modifiers or pragmas and be enabled locally. Examples: OverlappingInstances (this is already done!), NoMonomorphismRestriction, DeepSubsumption(*), UndecidableSuperClasses, NoMonoLocalBinds, etc.

I think it's worth making a further distinction according to whether the relaxation is thought to be unsound or not-well-founded for some reason (NoMonoLocalBinds, DeepSubsumption) and those that are well understood and not problematic at all (NoMonomorphismRestriction). The latter should just be treated like the syntax extensions: either experimental or enabled by default.

...

C. Extensions that change the compilation pipeline. These need to remain as configuration flags. Examples: CPP, TemplateHaskell.

...

D. Extensions that create variants of the language by changing semantics of existing constructs. I'm not quite sure what to do with these, but they

It's clear that CPP needs to remain as a flag because it does bad things to the syntax like breaking multiline strings and doing strange things to `##`. But it's less clear to me that TemplateHaskell is in this category. Isn't it just an extension that enables new syntax? Yes there are *practical* reasons why we might not want it on by default, because it makes compilation slower and whatnot, but isn't that all it is? probably need to remain configuration flags. Even better if they could be enabled locally within a file, though. We should probably try to avoid doing this in the future, though the pain may be worth it. Examples: RebindableSyntax, Strict, OverloadedXXX, etc. Again I think we could refine this. Clearly RebindableSyntax and Strict are not features that we would ever want to be on by default, but OverloadedStrings definitely is, and for me belongs in the category of language extensions that are either in GHC20xx now or will be later. Cheers Simon On Tue, 13 Dec 2022 at 09:43, Arnaud Spiwack wrote:

...

Thanks Richard for answering more comprehensively than I could have done myself. Simon: do you feel that Richard's email answers your question?

On Fri, 9 Dec 2022 at 19:57, Joachim Breitner wrote:

...
Hi,

this categorization is very helpful, I’ve been thinking about that as well recently. Especially it’s worth keeping in mind that some language extensions probably wouldn’t be language extensions these days, but some other kind of flag (CPP, Safe, Trustworthy), and as you say shouldn’t get in the way of finding a more coherent story for the others.

I think we should keep separate the category

F: Enables new language features with not just a local (usually) syntactic effect. (Litmus test: will a user of a module with that extension tell). Mostly all the type-level feature extension (GADTs, LinearTypes, TypeFamilies etc.)

Some of these are also guarded by “new syntax” of sorts, but I think they are fundamentally different from your category A. These are, in a way, the most interesting ones!

Cheers, Joachim

Am Freitag, dem 09.12.2022 um 14:21 +0000 schrieb Richard Eisenberg:

...
Glancing through the list of extensions, I see a few broad categories:

A. Extensions that simply enable new syntax. If users still want fine control over whether this syntax is allowed, each such extension could be converted to a warning -- but then all these extensions (except ones that are still experimental!) would be on by default. Maybe the warnings would be -Werror by default -- not sure. Examples: GADTSyntax, Arrows, InstanceSigs, StandaloneDeriving, and many more.

B. Extensions that allow violation of some general principle that holds elsewhere. These should be replaced by modifiers or pragmas and be enabled locally. Examples: OverlappingInstances (this is already done!), NoMonomorphismRestriction, DeepSubsumption(*), UndecidableSuperClasses, NoMonoLocalBinds, etc.

(*): Given the hue and cry about this one, perhaps there should be a flag to control the behavior.

C. Extensions that change the compilation pipeline. These need to remain as configuration flags. Examples: CPP, TemplateHaskell.

D. Extensions that create variants of the language by changing semantics of existing constructs. I'm not quite sure what to do with these, but they probably need to remain configuration flags. Even better if they could be enabled locally within a file, though. We should probably try to avoid doing this in the future, though the pain may be worth it. Examples: RebindableSyntax, Strict, OverloadedXXX, etc.

Maybe some extensions fail to be categorized here, but this covers the vast, vast majority.

-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ 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

Richard Eisenberg

18 Dec 18 Dec

3:54 a.m.

...

On Dec 14, 2022, at 6:05 AM, Simon Marlow wrote:

It's clear that CPP needs to remain as a flag because it does bad things to the syntax like breaking multiline strings and doing strange things to `##`. But it's less clear to me that TemplateHaskell is in this category. Isn't it just an extension that enables new syntax? Yes there are *practical* reasons why we might not want it on by default, because it makes compilation slower and whatnot, but isn't that all it is?

I somehow missed this, and more surprisingly just now found it. TemplateHaskell isn't just for new syntax primarily because it has important interactions around cross-compilation. If/when GHC has a comprehensive story around cross-compilation, TH will change the way the pipeline works. It was this concern that suggested it should be lumped with CPP. (TemplateHaskellQuotes are a different story -- that's just syntax.) Richard

Simon Marlow

3 Jan 3 Jan

9:32 a.m.

On Sun, 18 Dec 2022 at 03:54, Richard Eisenberg wrote:

...

On Dec 14, 2022, at 6:05 AM, Simon Marlow wrote:

It's clear that CPP needs to remain as a flag because it does bad things to the syntax like breaking multiline strings and doing strange things to `##`. But it's less clear to me that TemplateHaskell is in this category. Isn't it just an extension that enables new syntax? Yes there are *practical* reasons why we might not want it on by default, because it makes compilation slower and whatnot, but isn't that all it is?

I somehow missed this, and more surprisingly just now found it.

TemplateHaskell isn't just for new syntax primarily because it has important interactions around cross-compilation. If/when GHC has a comprehensive story around cross-compilation, TH will change the way the pipeline works. It was this concern that suggested it should be lumped with CPP. (TemplateHaskellQuotes are a different story -- that's just syntax.)

I think of cross-compilation as just a tooling issue that affects how you actually *implement* TH, but not something that changes what it means. Or perhaps I'm wrong? Is there a way in which enabling TH will change the meaning of a program that doesn't use any TH? Cheers Simon

Richard Eisenberg

1:17 p.m.

...

On Jan 3, 2023, at 4:32 AM, Simon Marlow wrote:

I think of cross-compilation as just a tooling issue that affects how you actually *implement* TH, but not something that changes what it means. Or perhaps I'm wrong? Is there a way in which enabling TH will change the meaning of a program that doesn't use any TH?

It means you have to be able to compile code that targets the host, not just the target. I suppose this property is also required by GHCi, but it's otherwise unrequired (I think). TH also affects recompilation-avoidance computations. Maybe it makes sense to use the existence of an actual splice to control this all, though, so we could plausibly put TH in the "just allows new syntax" category. Richard

921

Age (days ago)

953

Last active (days ago)

List overview

Download

22 comments

7 participants

participants (7)

Adam Gundry
Arnaud Spiwack
Chris Dornan
Joachim Breitner
Richard Eisenberg
Simon Marlow
Simon Peyton Jones

Why not?, rather than, why?

tags

participants (7)