Dear GHC steering committee A month ago I wrote to you concerning GHC Proposal 601 about GHC extensions https://github.com/david-christiansen/ghc-proposals/blob/extension-lifecycle... . We propose a categorization scheme for Haskell language extensions. This

scheme is simple, in that there are few categories that are described in terms of the user-relevant aspects, and it is actionable, in that it suggests concrete changes to the warning system of GHC that allow users to express their own risk tolerance and get guidance as they upgrade their compiler

It's holiday time I know, but still, I did not get a single reply. Is that because you all love it or you all hate it? RSVP! I propose acceptance, modulo a few clarifications which I have posted on the discussion thread. Please reply, yea or nay. Simon On Tue, 25 Jul 2023 at 15:58, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

Dear GHC Steering Committee

Proposal #601 https://github.com/david-christiansen/ghc-proposals/blob/extension-lifecycle... says

We propose a categorization scheme for Haskell language extensions. This scheme is simple, in that there are few categories that are described in terms of the user-relevant aspects, and it is actionable, in that it suggests concrete changes to the warning system of GHC that allow users to express their own risk tolerance and get guidance as they upgrade their compiler

I'm happy with this proposal: it seems simple, comprehensible, and actionable.

The only question in my mind is whether it is worth the bother. I'd love to hear from the practitioners on the committee.

But I propose that we accept it.

Simon

On Mon, 24 Jul 2023 at 14:39, Joachim Breitner wrote:

...

Dear Committee,

David Thrane Christiansen suggested to categorize extensions into Experimental, Mature, Deprecated and Legacy, and add warning flag to GHC that allow users to be warned about (or shouted at for) using such extensions, if they choose so.

https://github.com/ghc-proposals/ghc-proposals/pull/601

https://github.com/david-christiansen/ghc-proposals/blob/extension-lifecycle...

Because of the meta-like aspect of this proposal, I’d like to assign this to Simon PJ.

Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process

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

Hi, I am lukewarm on the proposal. Of course it would be nice to have such clear signal. But it’s going to be a lot of work to categorize all extensions initially, and then update this categorization as we go. Given that even defining a subset of “very stable and mature” (AKA GHC20xx) is something that was quite some effort, I am not fully optimistic that we’ll be able to deliver. But we can at least say we’d like to try, and then see how the categorization goes, so yea from me. Cheers, Joachim Am Donnerstag, dem 24.08.2023 um 16:42 +0100 schrieb Simon Peyton Jones:

Dear GHC steering committee

A month ago I wrote to you concerning GHC Proposal 601 about GHC extensions.

...

We propose a categorization scheme for Haskell language extensions. This scheme is simple, in that there are few categories that are described in terms of the user-relevant aspects, and it is actionable, in that it suggests concrete changes to the warning system of GHC that allow users to express their own risk tolerance and get guidance as they upgrade their compiler

It's holiday time I know, but still, I did not get a single reply.  Is that because you all love it or you all hate it?  RSVP!

I propose acceptance, modulo a few clarifications which I have posted on the discussion thread.

Please reply, yea or nay.

Simon

On Tue, 25 Jul 2023 at 15:58, Simon Peyton Jones wrote:

...

Dear GHC Steering Committee

Proposal #601 says

We propose a categorization scheme for Haskell language extensions. This scheme is simple, in that there are few categories that are described in terms of the user-relevant aspects, and it is actionable, in that it suggests concrete changes to the warning system of GHC that allow users to express their own risk tolerance and get guidance as they upgrade their compiler

I'm happy with this proposal: it seems simple, comprehensible, and actionable. 

The only question in my mind is whether it is worth the bother.  I'd love to hear from the practitioners on the committee.

But I propose that we accept it.

Simon

On Mon, 24 Jul 2023 at 14:39, Joachim Breitner wrote:

...

Dear Committee,

David Thrane Christiansen suggested to categorize extensions into Experimental, Mature, Deprecated and Legacy, and add warning flag to GHC that allow users to be warned about (or shouted at for) using such extensions, if they choose so.

https://github.com/ghc-proposals/ghc-proposals/pull/601 https://github.com/david-christiansen/ghc-proposals/blob/extension-lifecycle...

Because of the meta-like aspect of this proposal, I’d like to assign this to Simon PJ.

Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process

Cheers, Joachim

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

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

I've posted on the proposal. I won't stand in the way of a proposal that has generated positive feedback such as this one, but I worry we've missed the head of the nail here by a little bit. And adopting this proposal has a very real cost, in that it adds another layer of bureaucracy for Haskellers. Richard

On Aug 25, 2023, at 3:39 AM, Arnaud Spiwack wrote:

I'm rather agnostic on the proposal. I'm actually not convinced it solves a real problem for users (though I can see how this categorisation would inform our stance on backward compatibility, so it can be very useful for us steering committee), on the other hand, the proposal seems to be received with a lot of enthusiasm.

On Thu, 24 Aug 2023 at 22:21, Joachim Breitner mailto:mail@joachim-breitner.de> wrote: Hi,

I am lukewarm on the proposal. Of course it would be nice to have such clear signal. But it’s going to be a lot of work to categorize all extensions initially, and then update this categorization as we go. Given that even defining a subset of “very stable and mature” (AKA GHC20xx) is something that was quite some effort, I am not fully optimistic that we’ll be able to deliver.

But we can at least say we’d like to try, and then see how the categorization goes, so yea from me.

Cheers, Joachim

Am Donnerstag, dem 24.08.2023 um 16:42 +0100 schrieb Simon Peyton Jones:

...

Dear GHC steering committee

A month ago I wrote to you concerning GHC Proposal 601 about GHC extensions.

...

We propose a categorization scheme for Haskell language extensions. This scheme is simple, in that there are few categories that are described in terms of the user-relevant aspects, and it is actionable, in that it suggests concrete changes to the warning system of GHC that allow users to express their own risk tolerance and get guidance as they upgrade their compiler

It's holiday time I know, but still, I did not get a single reply. Is that because you all love it or you all hate it? RSVP!

I propose acceptance, modulo a few clarifications which I have posted on the discussion thread.

Please reply, yea or nay.

Simon

On Tue, 25 Jul 2023 at 15:58, Simon Peyton Jones mailto:simon.peytonjones@gmail.com> wrote:

...

Dear GHC Steering Committee

Proposal #601 says

We propose a categorization scheme for Haskell language extensions. This scheme is simple, in that there are few categories that are described in terms of the user-relevant aspects, and it is actionable, in that it suggests concrete changes to the warning system of GHC that allow users to express their own risk tolerance and get guidance as they upgrade their compiler

I'm happy with this proposal: it seems simple, comprehensible, and actionable.

The only question in my mind is whether it is worth the bother. I'd love to hear from the practitioners on the committee.

But I propose that we accept it.

Simon

On Mon, 24 Jul 2023 at 14:39, Joachim Breitner mailto:mail@joachim-breitner.de> wrote:

...

Dear Committee,

David Thrane Christiansen suggested to categorize extensions into Experimental, Mature, Deprecated and Legacy, and add warning flag to GHC that allow users to be warned about (or shouted at for) using such extensions, if they choose so.

https://github.com/ghc-proposals/ghc-proposals/pull/601 https://github.com/ghc-proposals/ghc-proposals/pull/601 https://github.com/david-christiansen/ghc-proposals/blob/extension-lifecycle... https://github.com/david-christiansen/ghc-proposals/blob/extension-lifecycle...

Because of the meta-like aspect of this proposal, I’d like to assign this to Simon PJ.

Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process https://github.com/ghc-proposals/ghc-proposals#committee-process

Cheers, Joachim

_______________________________________________ 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

-- 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

-- Arnaud Spiwack Director, Research at https://moduscreate.com https://moduscreate.com/ and https://tweag.io https://tweag.io/. _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

I am sorry Simon, Because I was so heavily involved in its preparation I assumed my support for the proposal was a given. I enthusiastically support this proposal. I cannot overemphasise how import I think it is that 1) we as a committee clarify for ourselves the status of these extensions and 2) how useful I think it is for developers to have ready access such a definitive taxonomy. Of course it doesn't solve all of our problems, but let's build on it and the feedback we get from the community. Chris

On 1 Sep 2023, at 10:37, Simon Peyton Jones wrote:

Dear Simon, Vlad, Eric, Chris, Moritz

I would love to hear from you about this proposal. Please.

I plan to accept it unless I hear dissent. But I would much rather have an explicit response from you than take silence as assent. You are a member of the committee, after all!

My apologies if I have missed your reply

Simon

On Thu, 24 Aug 2023 at 16:42, Simon Peyton Jones mailto:simon.peytonjones@gmail.com> wrote:

...

Dear GHC steering committee

A month ago I wrote to you concerning GHC Proposal 601 about GHC extensions https://github.com/david-christiansen/ghc-proposals/blob/extension-lifecycle....

...

We propose a categorization scheme for Haskell language extensions. This scheme is simple, in that there are few categories that are described in terms of the user-relevant aspects, and it is actionable, in that it suggests concrete changes to the warning system of GHC that allow users to express their own risk tolerance and get guidance as they upgrade their compiler

It's holiday time I know, but still, I did not get a single reply. Is that because you all love it or you all hate it? RSVP!

I propose acceptance, modulo a few clarifications which I have posted on the discussion thread.

Please reply, yea or nay.

Simon

On Tue, 25 Jul 2023 at 15:58, Simon Peyton Jones mailto:simon.peytonjones@gmail.com> wrote:

...

Dear GHC Steering Committee

Proposal #601 https://github.com/david-christiansen/ghc-proposals/blob/extension-lifecycle... says

We propose a categorization scheme for Haskell language extensions. This scheme is simple, in that there are few categories that are described in terms of the user-relevant aspects, and it is actionable, in that it suggests concrete changes to the warning system of GHC that allow users to express their own risk tolerance and get guidance as they upgrade their compiler

I'm happy with this proposal: it seems simple, comprehensible, and actionable.

The only question in my mind is whether it is worth the bother. I'd love to hear from the practitioners on the committee.

But I propose that we accept it.

Simon

On Mon, 24 Jul 2023 at 14:39, Joachim Breitner mailto:mail@joachim-breitner.de> wrote:

...

Dear Committee,

David Thrane Christiansen suggested to categorize extensions into Experimental, Mature, Deprecated and Legacy, and add warning flag to GHC that allow users to be warned about (or shouted at for) using such extensions, if they choose so.

https://github.com/ghc-proposals/ghc-proposals/pull/601 https://github.com/david-christiansen/ghc-proposals/blob/extension-lifecycle...

Because of the meta-like aspect of this proposal, I’d like to assign this to Simon PJ.

Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process

Cheers, Joachim

-- Joachim Breitner mail@joachim-breitner.de mailto:mail@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

A few things make this not a straightforward thumbs up for me, though I'm not strongly against. What is the interaction with GHC20xx? Presumably we want to say something like GHC20xx will never include any Deprecated or Legacy extensions? What about Unsable? if an extension transitions from Stable -> Legacy, would we remove it from the next GHC20xx? Something doesn't feel quite right about the warning system. If a module can start with {-# OPTIONS_GHC -Wno-XDeprecated #-} {-# LANGUAGE OverlappingInstances #-} and silently use an extension that the {build system, user, project} wanted to disallow, have we achieved anything? Compare this to the current situation, where the environment can say -XNoOverlappingInstances and code can override that with {-# LANGUAGE OverlappingInstances #-} - there's essentially no difference, we just added another layer of disable/override that isn't buying us anything. (note I'm viewing this through the spectacles of -Werror, because I've come to believe that warnings are essentially not useful unless given teeth with -Werror.) Cheers Simon On Fri, 1 Sept 2023 at 13:18, Vladislav Zavialov wrote:

I agree that we need a categorisation of extension language flags, but I'm not convinced that {Stable, Unstable, Deprecated, Legacy} is the right set of labels. In fact, I wouldn't want to commit to any particular categorisation before we actually go through all the extensions in GHC and see for ourselves that they can be adequately categorized according to the proposed system.

The proposal says "classifications of individual language extensions will be left to a future proposal". Well, I am skeptical that this separation makes sense. I would much prefer if we were discussing a concrete categorisation proposal, not just a set of four labels whose implications I can't fully grasp.

Vlad

On Fri, Sep 1, 2023 at 11:37 AM Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

...

Dear Simon, Vlad, Eric, Chris, Moritz

I would love to hear from you about this proposal. *Please*.

I plan to accept it unless I hear dissent. But I would much rather have an explicit response from you than take silence as assent. You are a member of the committee, after all!

My apologies if I have missed your reply

Simon

I've just posted on the GitHub ticket. I remain against the proposal in its current form, mostly because it means (if I understand correctly) that everyone who says `default-language: Haskell2010` will get warnings. Richard

On Sep 1, 2023, at 12:21 PM, Simon Marlow wrote:

On Fri, 1 Sept 2023 at 17:17, Simon Marlow mailto:marlowsd@gmail.com> wrote: A few things make this not a straightforward thumbs up for me, though I'm not strongly against.

What is the interaction with GHC20xx? Presumably we want to say something like GHC20xx will never include any Deprecated or Legacy extensions? What about Unsable? if an extension transitions from Stable -> Legacy, would we remove it from the next GHC20xx?

Ah, I just noticed that the proposal does say something about this:

For existing, or future, language sets such as GHC2021 or Haskell98, it is expected that none of the contained extensions would be Unstable. However, this proposal does not seek to impose any particular policy on the inclusion of extensions into language sets - the developers and the steering committee are always in the best position to make a decision about a concrete extension and extension set.

OK.

Simon

Something doesn't feel quite right about the warning system. If a module can start with

{-# OPTIONS_GHC -Wno-XDeprecated #-} {-# LANGUAGE OverlappingInstances #-}

and silently use an extension that the {build system, user, project} wanted to disallow, have we achieved anything? Compare this to the current situation, where the environment can say -XNoOverlappingInstances and code can override that with {-# LANGUAGE OverlappingInstances #-} - there's essentially no difference, we just added another layer of disable/override that isn't buying us anything.

(note I'm viewing this through the spectacles of -Werror, because I've come to believe that warnings are essentially not useful unless given teeth with -Werror.)

Cheers Simon

On Fri, 1 Sept 2023 at 13:18, Vladislav Zavialov mailto:vlad.z.4096@gmail.com> wrote: I agree that we need a categorisation of extension language flags, but I'm not convinced that {Stable, Unstable, Deprecated, Legacy} is the right set of labels. In fact, I wouldn't want to commit to any particular categorisation before we actually go through all the extensions in GHC and see for ourselves that they can be adequately categorized according to the proposed system.

The proposal says "classifications of individual language extensions will be left to a future proposal". Well, I am skeptical that this separation makes sense. I would much prefer if we were discussing a concrete categorisation proposal, not just a set of four labels whose implications I can't fully grasp.

Vlad

On Fri, Sep 1, 2023 at 11:37 AM Simon Peyton Jones mailto:simon.peytonjones@gmail.com> wrote: Dear Simon, Vlad, Eric, Chris, Moritz

I would love to hear from you about this proposal. Please.

I plan to accept it unless I hear dissent. But I would much rather have an explicit response from you than take silence as assent. You are a member of the committee, after all!

My apologies if I have missed your reply

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

This is a bit hard for me. But here it goes. IMO _every_ extension enabled in the public release of GHC _are_ stable by definition. It's a stable release, thus the available extensions are also those the GHC team decides to be stable. While I'm very much in favour of having a clearer picture of what we currently consider extensions to be. I do not believe _Unstable_ extensions should ever be part of a public stable release. I also don't think the distinction between Legacy and Deprecated is easy to understand for the end user. Either the extension is supposed to be used, or not. Stable or Deprecated. The fact that we'll keep some extension around for what is effectively an infinite deprecation period is a technicality in my opinion. This puts my vote probably fairly square into Alternative 6.3; I don't think 6.1 is useful. Having to tell people to RTFM comes across pretty passive aggressive all the time. Also it's the compiler's knowledge as to what is deprecated or not and it should report this. 6.2 is even worse, as it now has two components that need to be kept in sync, while the extensions are pretty much integral to GHC. Hence GHC has this knowledge and should report it. 6.4 and 6.5 are in the same line as the Legacy/Deprecated extra complexity bucket to me. Again, what's shipped in the stable release _is_ stable to me. And as such any _unstable_ extensions should _not_ be in stable ghc releases. Other languages have separate channels for this. I've also proposed multiple times to have either two separate development branches: stable + experimental (stable being periodically merged into experimental), and cutting _stable_ releases from stable, potentially offering _experimental_ releases from the experimental branch. And alternative model is to have a single branch (as I do understand that getting stuff from the experimental branch migrated into stable could be a bit messy), but have every _unstable_ extension behind a -DEXPERIMENTAL compile time flag. The same flag could be used to produce experimental ghc releases for 3rd parties to consume. Again, my point is that Unstable extensions should _not_ be in the Stable ghc releases, and as such anything that's in the stable ghc releases should be considered stable. If I want to play with bleeding edge features, I should have to use a completely separate compiler for this (again, other languages _do_ follow this approach). And that leaves us with stable extensions in GHC, for which we eventually see that we have better facilities now or learned over time that these extensions (despite being stable), have reached their end of life. In that case they should be marked as deprecated with appropriately long deprecation cycles. GHC already has a ton of flags, let's try not to add that many more to it. Ultimately someone needs to keep all of this in their head, while also trying to get their job done. And for some this job is 9-5, five days a week only; no late night hacking sessions, no weekend projects; but instead soccer practice, cycling, spending time with their family. If we want to make haskell successful, we need to make sure that in that people can be effective and productive and solve real world problems in the 40hs they have per week; and not study manuals, or flags (and if they see one of the many unknown flags, go study those flags) more than absolutely necessary to get work done. In summary, I don't see myself supporting this proposal as it adds too much complexity and sets in stone that unstable extensions are part of a stable compiler. I'm happy to see that the "only deprecations" option is listed as an alternative in 6.3, even though I do not agree with the assessment that we need more nuance for users. Extension in my opinion should only be stable, or deprecated. And the end user should never see unstable extensions, unless they _explicitly_ asked for an experimental/unstable compiler. Moritz On Sat, 2 Sept 2023 at 08:24, Eric Seidel wrote:

There's a non-normative and a normative component to this proposal.

The non-normative piece says that there should be a categorization scheme for language extensions. That is inarguable in my opinion. The proposal also suggests an initial framework of four categories, which seems like a reasonable place to start. (Vlad says we should first figure out how to map all extensions to the categories; I disagree. We can iterate on the categories over time, as needed.)

The normative piece of the proposal says that we should start warning on the use of any Deprecated, Unstable, or Legacy extensions. This seems like a reasonable ideal, but the practicality kind of hinges on the bucketing of specific extensions (and on Richard's question of how `default-language` is interpreted). The authors give some recommendations of how to bucket particular extensions, but it's not exhaustive and I also view it as the authors' desire rather than a specific commitment of the proposal.

So in my view:

* Yes, we should have a framework for categorizing the jungle of language extensions, and the proposal seems like a fine starting point. * Yes, we should have a set of warnings for users who would like to forbid certain categories of extensions. * We should probably defer any decisions about default enablement of warnings until we have a complete proposed categorization. And that discussion should include some analysis of the pervasiveness of "deprecated", "unstable", and "legacy" extensions so we can judge the amount of churn. Just like any other discussion about deprecation.

Eric

...

I've just posted on the GitHub ticket. I remain against the proposal in its current form, mostly because it means (if I understand correctly) that everyone who says `default-language: Haskell2010` will get warnings.

Richard

...

On Sep 1, 2023, at 12:21 PM, Simon Marlow wrote:

On Fri, 1 Sept 2023 at 17:17, Simon Marlow wrote:

...

A few things make this not a straightforward thumbs up for me, though I'm not strongly against.

What is the interaction with GHC20xx? Presumably we want to say something like GHC20xx will never include any Deprecated or Legacy extensions? What about Unsable? if an extension transitions from Stable -> Legacy, would we remove it from the next GHC20xx?

Ah, I just noticed that the proposal does say something about this:

...

For existing, or future, language sets such as `GHC2021` or `Haskell98`, it is expected that none of the contained extensions would be `Unstable`. However, this proposal does not seek to impose any particular

...

...

OK.

Simon

...

Something doesn't feel quite right about the warning system. If a

module can start with

...

...

{-# OPTIONS_GHC -Wno-XDeprecated #-} {-# LANGUAGE OverlappingInstances #-}

and silently use an extension that the {build system, user, project}

wanted to disallow, have we achieved anything? Compare this to the current situation, where the environment can say -XNoOverlappingInstances and code can override that with {-# LANGUAGE OverlappingInstances #-} - there's essentially no difference, we just added another layer of disable/override

...

...

...

(note I'm viewing this through the spectacles of -Werror, because I've

come to believe that warnings are essentially not useful unless given teeth with -Werror.)

...

Cheers Simon

On Fri, 1 Sept 2023 at 13:18, Vladislav Zavialov <

vlad.z.4096@gmail.com> wrote:

...

...

I agree that we need a categorisation of extension language flags, but I'm not convinced that {Stable, Unstable, Deprecated, Legacy} is the right set of labels. In fact, I wouldn't want to commit to any particular categorisation before we actually go through all the extensions in GHC and see for ourselves that they can be adequately categorized according to the

On Fri, Sep 1, 2023, at 12:56, Richard Eisenberg wrote: policy on the inclusion of extensions into language sets - the developers and the steering committee are always in the best position to make a decision about a concrete extension and extension set. that isn't buying us anything. proposed system.

...

...

...

...

The proposal says "classifications of individual language extensions

will be left to a future proposal". Well, I am skeptical that this separation makes sense. I would much prefer if we were discussing a concrete categorisation proposal, not just a set of four labels whose implications I can't fully grasp.

...

Vlad

On Fri, Sep 1, 2023 at 11:37 AM Simon Peyton Jones <

simon.peytonjones@gmail.com> wrote:

...

...

Dear Simon, Vlad, Eric, Chris, Moritz

I would love to hear from you about this proposal. *Please*.

I plan to accept it unless I hear dissent. But I would much rather have an explicit response from you than take silence as assent. You are a member of the committee, after all!

My apologies if I have missed your reply

Simon

---

ghc-steering-committee mailing list ghc-steering-committee@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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

---

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

On Sat, 2 Sep 2023 at 9:56 PM, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

Again, my point is that Unstable extensions should _not_ be in the Stable

...

ghc releases, and as such anything that's in

the stable ghc releases should be considered stable.

...

I don't agree with this. To follow your plan we would have to do this:

- Release ghc-9.10 - Release ghc-9.10-experimental - The two are bit-for-bit identical, except that in ghc-9.10 a bunch experimental extensions, available in ghc-9.10-experimental, are unavailable

I do not consider this significantly more work it’s really just passing -DEXPERIMENTAL to the build. But we don’t even need those during our _stable_ build releases. We have nighties and we could build nightlies with -DEXPERIMENTAL. Thus everyone who wants unstable/experimental features can get them through nightly builds.

This is also what other languages do. You clearly feel strongly about this so I feel I am missing something

important.

Yes, very much so. Maybe you want -Werror=XExerimental to be the default? So that to use an

experimental feature the user would not only have to invoke it by name, but also switch off the error its use triggers. That would cause a huge amount of transitional churn which users would hate us for, but I can see some logic in it.

That’s why I’m advocating for a separate build. So they don’t get any warning and can enable the features to their heats content. But if you do not use the experimental build (e.g. a nightly) you can not, not even by accident, enable those features. By having them in release builds you open the door to lengthy discussions of why some features a _stable_ compiler offers should _not_ be used. And then have to have reviewers be careful about which extensions and other features are enabled or not. It basically puts a lot of work on teams to reign in on accidental usage of experimental/unstable features. So then we end up building tools on-top, lingers, CI checks to run with -Werror=XExerimental, … all just to ensure something which should not be there by construction. I simply do not believe that experimental or unstable features should be part of stable releases. What is the definition of stable at that point? The practice that we put experimental/unstable features into our stable releases is something this proposal seems to cement, which is why I’m so much against it in this form. I fundamentally believe that if we put experimental/unstable features into our releases we must not call them stable releases. So we are left with experimental/unstable releases only. We’ve had discussions around this before: - Michael Snoymans Boring Haskell[1] - Simple Haskell[2] - George Wilson’s talk on Cultivating an Engineering Dialect[3] I hope this helps clarify my stance on this proposal. Moritz — [1]: https://www.snoyman.com/blog/2019/11/boring-haskell-manifesto/ [2]: https://www.simplehaskell.org [3]: https://www.youtube.com/watch?v=L4h6VegK1BI On Sat, 2 Sept 2023 at 03:49, Moritz Angermann

wrote:

...

This is a bit hard for me. But here it goes.

IMO _every_ extension enabled in the public release of GHC _are_ stable by definition. It's a stable release, thus the available extensions are also those the GHC team decides to be stable. While I'm very much in favour of having a clearer picture of what we currently consider extensions to be. I do not believe _Unstable_ extensions should ever be part of a public stable release. I also don't think the distinction between Legacy and Deprecated is easy to understand for the end user. Either the extension is supposed to be used, or not. Stable or Deprecated. The fact that we'll keep some extension around for what is effectively an infinite deprecation period is a technicality in my opinion.

This puts my vote probably fairly square into Alternative 6.3; I don't think 6.1 is useful. Having to tell people to RTFM comes across pretty passive aggressive all the time. Also it's the compiler's knowledge as to what is deprecated or not and it should report this. 6.2 is even worse, as it now has two components that need to be kept in sync, while the extensions are pretty much integral to GHC. Hence GHC has this knowledge and should report it. 6.4 and 6.5 are in the same line as the Legacy/Deprecated extra complexity bucket to me.

Again, what's shipped in the stable release _is_ stable to me. And as such any _unstable_ extensions should _not_ be in stable ghc releases. Other languages have separate channels for this. I've also proposed multiple times to have either two separate development branches: stable + experimental (stable being periodically merged into experimental), and cutting _stable_ releases from stable, potentially offering _experimental_ releases from the experimental branch. And alternative model is to have a single branch (as I do understand that getting stuff from the experimental branch migrated into stable could be a bit messy), but have every _unstable_ extension behind a -DEXPERIMENTAL compile time flag. The same flag could be used to produce experimental ghc releases for 3rd parties to consume.

Again, my point is that Unstable extensions should _not_ be in the Stable ghc releases, and as such anything that's in the stable ghc releases should be considered stable. If I want to play with bleeding edge features, I should have to use a completely separate compiler for this (again, other languages _do_ follow this approach).

And that leaves us with stable extensions in GHC, for which we eventually see that we have better facilities now or learned over time that these extensions (despite being stable), have reached their end of life. In that case they should be marked as deprecated with appropriately long deprecation cycles.

GHC already has a ton of flags, let's try not to add that many more to it. Ultimately someone needs to keep all of this in their head, while also trying to get their job done. And for some this job is 9-5, five days a week only; no late night hacking sessions, no weekend projects; but instead soccer practice, cycling, spending time with their family. If we want to make haskell successful, we need to make sure that in that people can be effective and productive and solve real world problems in the 40hs they have per week; and not study manuals, or flags (and if they see one of the many unknown flags, go study those flags) more than absolutely necessary to get work done.

In summary, I don't see myself supporting this proposal as it adds too much complexity and sets in stone that unstable extensions are part of a stable compiler. I'm happy to see that the "only deprecations" option is listed as an alternative in 6.3, even though I do not agree with the assessment that we need more nuance for users. Extension in my opinion should only be stable, or deprecated. And the end user should never see unstable extensions, unless they _explicitly_ asked for an experimental/unstable compiler.

Moritz

On Sat, 2 Sept 2023 at 08:24, Eric Seidel wrote:

...

There's a non-normative and a normative component to this proposal.

The non-normative piece says that there should be a categorization scheme for language extensions. That is inarguable in my opinion. The proposal also suggests an initial framework of four categories, which seems like a reasonable place to start. (Vlad says we should first figure out how to map all extensions to the categories; I disagree. We can iterate on the categories over time, as needed.)

The normative piece of the proposal says that we should start warning on the use of any Deprecated, Unstable, or Legacy extensions. This seems like a reasonable ideal, but the practicality kind of hinges on the bucketing of specific extensions (and on Richard's question of how `default-language` is interpreted). The authors give some recommendations of how to bucket particular extensions, but it's not exhaustive and I also view it as the authors' desire rather than a specific commitment of the proposal.

So in my view:

* Yes, we should have a framework for categorizing the jungle of language extensions, and the proposal seems like a fine starting point. * Yes, we should have a set of warnings for users who would like to forbid certain categories of extensions. * We should probably defer any decisions about default enablement of warnings until we have a complete proposed categorization. And that discussion should include some analysis of the pervasiveness of "deprecated", "unstable", and "legacy" extensions so we can judge the amount of churn. Just like any other discussion about deprecation.

Eric

...

I've just posted on the GitHub ticket. I remain against the proposal in its current form, mostly because it means (if I understand correctly) that everyone who says `default-language: Haskell2010` will get warnings.

Richard

...

On Sep 1, 2023, at 12:21 PM, Simon Marlow wrote:

On Fri, 1 Sept 2023 at 17:17, Simon Marlow wrote:

...

A few things make this not a straightforward thumbs up for me,

...

...

...

What is the interaction with GHC20xx? Presumably we want to say

something like GHC20xx will never include any Deprecated or Legacy extensions? What about Unsable? if an extension transitions from Stable -> Legacy, would we remove it from the next GHC20xx?

Ah, I just noticed that the proposal does say something about this:

...

For existing, or future, language sets such as `GHC2021` or `Haskell98`, it is expected that none of the contained extensions would be `Unstable`. However, this proposal does not seek to impose any particular

...

...

OK.

Simon

...

Something doesn't feel quite right about the warning system. If a

module can start with

...

...

{-# OPTIONS_GHC -Wno-XDeprecated #-} {-# LANGUAGE OverlappingInstances #-}

and silently use an extension that the {build system, user, project}

wanted to disallow, have we achieved anything? Compare this to the current situation, where the environment can say -XNoOverlappingInstances and code can override that with {-# LANGUAGE OverlappingInstances #-} - there's essentially no difference, we just added another layer of disable/override

...

...

...

(note I'm viewing this through the spectacles of -Werror, because

I've come to believe that warnings are essentially not useful unless given teeth with -Werror.)

...

Cheers Simon

On Fri, 1 Sept 2023 at 13:18, Vladislav Zavialov <

vlad.z.4096@gmail.com> wrote:

...

> I agree that we need a categorisation of extension language flags, but I'm not convinced that {Stable, Unstable, Deprecated, Legacy} is the right set of labels. In fact, I wouldn't want to commit to any particular categorisation before we actually go through all the extensions in GHC and see for ourselves that they can be adequately categorized according to the

...

...

...

> > The proposal says "classifications of individual language extensions will be left to a future proposal". Well, I am skeptical that

On Fri, Sep 1, 2023, at 12:56, Richard Eisenberg wrote: though I'm not strongly against. policy on the inclusion of extensions into language sets - the developers and the steering committee are always in the best position to make a decision about a concrete extension and extension set. that isn't buying us anything. proposed system. this separation makes sense. I would much prefer if we were discussing a concrete categorisation proposal, not just a set of four labels whose implications I can't fully grasp.

...

...

...

> > Vlad > > On Fri, Sep 1, 2023 at 11:37 AM Simon Peyton Jones < simon.peytonjones@gmail.com> wrote: >> Dear Simon, Vlad, Eric, Chris, Moritz >> >> I would love to hear from you about this proposal. *Please*. >> >> I plan to accept it unless I hear dissent. But I would much rather have an explicit response from you than take silence as assent. You are a member of the committee, after all! >> >> My apologies if I have missed your reply >> >> Simon

---

ghc-steering-committee mailing list ghc-steering-committee@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org

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

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

How about —std=experimental then, if it needs to be a runtime flag due to CI constraints? Whether or not that flag is only exposed for nightly builds and not for release builds is another option. That should help with the CPP mess and CI load? On Sun, 3 Sep 2023 at 3:38 PM, Simon Marlow wrote:

On Sun, 3 Sept 2023 at 01:16, Moritz Angermann wrote:

...

On Sat, 2 Sep 2023 at 9:56 PM, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

...

Again, my point is that Unstable extensions should _not_ be in the

...

Stable ghc releases, and as such anything that's in

the stable ghc releases should be considered stable.

...

I don't agree with this. To follow your plan we would have to do this:

- Release ghc-9.10 - Release ghc-9.10-experimental - The two are bit-for-bit identical, except that in ghc-9.10 a bunch experimental extensions, available in ghc-9.10-experimental, are unavailable

I do not consider this significantly more work it’s really just passing -DEXPERIMENTAL to the build. But we don’t even need those during our _stable_ build releases. We have nighties and we could build nightlies with -DEXPERIMENTAL. Thus everyone who wants unstable/experimental features can get them through nightly builds.

This seems impractical to me. Adding a CPP macro that changes the compiler doubles the amount of CI and release builds we have to do, and CI for GHC is barely practical as it is. We discourage the use of CPP for good reasons - it's much better to use runtime switches.

Cheers Simon

...

This is also what other languages do.

You clearly feel strongly about this so I feel I am missing something

...

important.

Yes, very much so.

Maybe you want -Werror=XExerimental to be the default? So that to use an

...

experimental feature the user would not only have to invoke it by name, but also switch off the error its use triggers. That would cause a huge amount of transitional churn which users would hate us for, but I can see some logic in it.

That’s why I’m advocating for a separate build. So they don’t get any warning and can enable the features to their heats content. But if you do not use the experimental build (e.g. a nightly) you can not, not even by accident, enable those features.

By having them in release builds you open the door to lengthy discussions of why some features a _stable_ compiler offers should _not_ be used. And then have to have reviewers be careful about which extensions and other features are enabled or not. It basically puts a lot of work on teams to reign in on accidental usage of experimental/unstable features. So then we end up building tools on-top, lingers, CI checks to run with -Werror=XExerimental, … all just to ensure something which should not be there by construction.

I simply do not believe that experimental or unstable features should be part of stable releases. What is the definition of stable at that point?

The practice that we put experimental/unstable features into our stable releases is something this proposal seems to cement, which is why I’m so much against it in this form. I fundamentally believe that if we put experimental/unstable features into our releases we must not call them stable releases. So we are left with experimental/unstable releases only.

We’ve had discussions around this before: - Michael Snoymans Boring Haskell[1] - Simple Haskell[2] - George Wilson’s talk on Cultivating an Engineering Dialect[3]

I hope this helps clarify my stance on this proposal.

Moritz

— [1]: https://www.snoyman.com/blog/2019/11/boring-haskell-manifesto/ [2]: https://www.simplehaskell.org [3]: https://www.youtube.com/watch?v=L4h6VegK1BI

On Sat, 2 Sept 2023 at 03:49, Moritz Angermann <

...

moritz.angermann@gmail.com> wrote:

...

This is a bit hard for me. But here it goes.

IMO _every_ extension enabled in the public release of GHC _are_ stable by definition. It's a stable release, thus the available extensions are also those the GHC team decides to be stable. While I'm very much in favour of having a clearer picture of what we currently consider extensions to be. I do not believe _Unstable_ extensions should ever be part of a public stable release. I also don't think the distinction between Legacy and Deprecated is easy to understand for the end user. Either the extension is supposed to be used, or not. Stable or Deprecated. The fact that we'll keep some extension around for what is effectively an infinite deprecation period is a technicality in my opinion.

This puts my vote probably fairly square into Alternative 6.3; I don't think 6.1 is useful. Having to tell people to RTFM comes across pretty passive aggressive all the time. Also it's the compiler's knowledge as to what is deprecated or not and it should report this. 6.2 is even worse, as it now has two components that need to be kept in sync, while the extensions are pretty much integral to GHC. Hence GHC has this knowledge and should report it. 6.4 and 6.5 are in the same line as the Legacy/Deprecated extra complexity bucket to me.

Again, what's shipped in the stable release _is_ stable to me. And as such any _unstable_ extensions should _not_ be in stable ghc releases. Other languages have separate channels for this. I've also proposed multiple times to have either two separate development branches: stable + experimental (stable being periodically merged into experimental), and cutting _stable_ releases from stable, potentially offering _experimental_ releases from the experimental branch. And alternative model is to have a single branch (as I do understand that getting stuff from the experimental branch migrated into stable could be a bit messy), but have every _unstable_ extension behind a -DEXPERIMENTAL compile time flag. The same flag could be used to produce experimental ghc releases for 3rd parties to consume.

Again, my point is that Unstable extensions should _not_ be in the Stable ghc releases, and as such anything that's in the stable ghc releases should be considered stable. If I want to play with bleeding edge features, I should have to use a completely separate compiler for this (again, other languages _do_ follow this approach).

And that leaves us with stable extensions in GHC, for which we eventually see that we have better facilities now or learned over time that these extensions (despite being stable), have reached their end of life. In that case they should be marked as deprecated with appropriately long deprecation cycles.

GHC already has a ton of flags, let's try not to add that many more to it. Ultimately someone needs to keep all of this in their head, while also trying to get their job done. And for some this job is 9-5, five days a week only; no late night hacking sessions, no weekend projects; but instead soccer practice, cycling, spending time with their family. If we want to make haskell successful, we need to make sure that in that people can be effective and productive and solve real world problems in the 40hs they have per week; and not study manuals, or flags (and if they see one of the many unknown flags, go study those flags) more than absolutely necessary to get work done.

In summary, I don't see myself supporting this proposal as it adds too much complexity and sets in stone that unstable extensions are part of a stable compiler. I'm happy to see that the "only deprecations" option is listed as an alternative in 6.3, even though I do not agree with the assessment that we need more nuance for users. Extension in my opinion should only be stable, or deprecated. And the end user should never see unstable extensions, unless they _explicitly_ asked for an experimental/unstable compiler.

Moritz

On Sat, 2 Sept 2023 at 08:24, Eric Seidel wrote:

...

There's a non-normative and a normative component to this proposal.

The non-normative piece says that there should be a categorization scheme for language extensions. That is inarguable in my opinion. The proposal also suggests an initial framework of four categories, which seems like a reasonable place to start. (Vlad says we should first figure out how to map all extensions to the categories; I disagree. We can iterate on the categories over time, as needed.)

The normative piece of the proposal says that we should start warning on the use of any Deprecated, Unstable, or Legacy extensions. This seems like a reasonable ideal, but the practicality kind of hinges on the bucketing of specific extensions (and on Richard's question of how `default-language` is interpreted). The authors give some recommendations of how to bucket particular extensions, but it's not exhaustive and I also view it as the authors' desire rather than a specific commitment of the proposal.

So in my view:

* Yes, we should have a framework for categorizing the jungle of language extensions, and the proposal seems like a fine starting point. * Yes, we should have a set of warnings for users who would like to forbid certain categories of extensions. * We should probably defer any decisions about default enablement of warnings until we have a complete proposed categorization. And that discussion should include some analysis of the pervasiveness of "deprecated", "unstable", and "legacy" extensions so we can judge the amount of churn. Just like any other discussion about deprecation.

Eric

...

I've just posted on the GitHub ticket. I remain against the proposal in its current form, mostly because it means (if I understand correctly) that everyone who says `default-language: Haskell2010` will get warnings.

Richard

> On Sep 1, 2023, at 12:21 PM, Simon Marlow wrote: > > On Fri, 1 Sept 2023 at 17:17, Simon Marlow wrote: >> A few things make this not a straightforward thumbs up for me,

...

>> >> What is the interaction with GHC20xx? Presumably we want to say something like GHC20xx will never include any Deprecated or Legacy extensions? What about Unsable? if an extension transitions from Stable -> Legacy, would we remove it from the next GHC20xx? > > Ah, I just noticed that the proposal does say something about this: > >> For existing, or future, language sets such as `GHC2021` or `Haskell98`, it is expected that none of the contained extensions would be `Unstable`. However, this proposal does not seek to impose any particular

...

> > OK. > > Simon > > >> >> Something doesn't feel quite right about the warning system. If a module can start with >> >> {-# OPTIONS_GHC -Wno-XDeprecated #-} >> {-# LANGUAGE OverlappingInstances #-} >> >> and silently use an extension that the {build system, user,

...

>> >> (note I'm viewing this through the spectacles of -Werror, because I've come to believe that warnings are essentially not useful unless given teeth with -Werror.) >> >> Cheers >> Simon >> >> On Fri, 1 Sept 2023 at 13:18, Vladislav Zavialov < vlad.z.4096@gmail.com> wrote: >>> I agree that we need a categorisation of extension language flags, but I'm not convinced that {Stable, Unstable, Deprecated, Legacy} is

...

>>> >>> The proposal says "classifications of individual language extensions will be left to a future proposal". Well, I am skeptical that

On Fri, Sep 1, 2023, at 12:56, Richard Eisenberg wrote: though I'm not strongly against. policy on the inclusion of extensions into language sets - the developers and the steering committee are always in the best position to make a decision about a concrete extension and extension set. project} wanted to disallow, have we achieved anything? Compare this to the current situation, where the environment can say -XNoOverlappingInstances and code can override that with {-# LANGUAGE OverlappingInstances #-} - there's essentially no difference, we just added another layer of disable/override that isn't buying us anything. the right set of labels. In fact, I wouldn't want to commit to any particular categorisation before we actually go through all the extensions in GHC and see for ourselves that they can be adequately categorized according to the proposed system. this separation makes sense. I would much prefer if we were discussing a concrete categorisation proposal, not just a set of four labels whose implications I can't fully grasp.

...

>>> >>> Vlad >>> >>> On Fri, Sep 1, 2023 at 11:37 AM Simon Peyton Jones < simon.peytonjones@gmail.com> wrote: >>>> Dear Simon, Vlad, Eric, Chris, Moritz >>>> >>>> I would love to hear from you about this proposal. *Please*. >>>> >>>> I plan to accept it unless I hear dissent. But I would much rather have an explicit response from you than take silence as assent. You are a member of the committee, after all! >>>> >>>> My apologies if I have missed your reply >>>> >>>> Simon > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee@haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org

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

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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

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

Adam, How can I support a proposal that cements a already firmly established practice, I fundamentally disagree with? Every extension in a stable GHC release by extension has to be stable, maybe deprecated. But stable. This proposal basically says it is ok to have unstable extensions in a stable GHC release. I do not believe that -WXUnstable should exist in a stable compiler. And from an end user perspective I think there can only be stable and deprecated extensions. GHC is already a highly complex piece of software from an end user perspective, let’s try to make it simpler not add even more complexity. I have no intentions to turn this proposal into a radical change to release practices. I have provided most of this for context as to why I can not see myself supporting this proposal as is. I can support a subset of the proposal. I do not see how I can support a this proposal in its entirety? Best, Moritz On Sun, 3 Sep 2023 at 4:59 PM, Adam Gundry wrote:

On 03/09/2023 01:15, Moritz Angermann wrote:

...

The practice that we put experimental/unstable features into our stable releases is something this proposal seems to cement, which is why I’m so much against it in this form.

But that practice is already firmly established (de facto), it's not something being introduced by this proposal! So while I understand your opposition to *the practice*, I'm struggling to understand the strength of your opposition to *the proposal*.

You're welcome to make the argument (in a subsequent proposal, perhaps) that GHC should more firmly gate access to unstable features. If anything, that would seem easier to specify once the proposal's approach clearly defines those features. And in the interim, at least the proposal makes it possible to switch off unstable features systematically.

So I understand that this proposal doesn't get you everything you want. But it seems like a reasonable interim step, and one that is more likely to command broad consensus than a radical change to release practices?

Best wishes,

Adam

-- 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

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

As a general principle, a deprecated feature should have an “end-of-life” date, ie when we expect to remove the feature entirely. Is a “legacy” feature just a deprecated feature with no (current) end-of-life date? Sent from my iPhone

On Sep 2, 2023, at 10:04, Adam Gundry wrote:

I'm in agreement with Eric here. Let's accept the proposal modulo the reservation that the default warning levels need to be decided in the follow-up proposal that categorises extensions. And we can always fine-tune the categories themselves at that point.

Moritz, I appreciate your view that mainline GHC releases shouldn't have any Unstable extensions, but we are a very long way from that point (and my sense is that getting there is neither practically possible nor desirable). Given that, I'd hope that this proposal is useful to you anyway: once the classification is done, at least it will be clearer which extensions are Unstable (and indeed you can argue for `-Werror=XUnstable`, or relatively easily produce GHC binaries for which that option is mandated).

I was originally sceptical of the Deprecated/Legacy distinction, but I've come to see it as useful. In my view:

* Legacy means "don't use this for new code, but there's no strong reason to move away from it". NPlusKPatterns (and indeed Haskell98 generally) is in this category.

* Deprecated means "expect support for this to be removed in the future, because there are compelling reasons to do so and a migration path to a better alternative". I don't think we should use this often (if at all), but that's a discussion that we can best have on a case-by-case basis once the framework is established.

Yes, this is slightly more complex than a boolean distinction. But I think it's not that hard to communicate, and it allows us to discourage beginners from using legacy features while still committing to supporting them over the long term.

Cheers,

Adam

...

On 02/09/2023 03:48, Moritz Angermann wrote: This is a bit hard for me. But here it goes. IMO _every_ extension enabled in the public release of GHC _are_ stable by definition. It's a stable release, thus the available extensions are also those the GHC team decides to be stable. While I'm very much in favour of having a clearer picture of what we currently consider extensions to be. I do not believe _Unstable_ extensions should ever be part of a public stable release. I also don't think the distinction between Legacy and Deprecated is easy to understand for the end user. Either the extension is supposed to be used, or not. Stable or Deprecated. The fact that we'll keep some extension around for what is effectively an infinite deprecation period is a technicality in my opinion. This puts my vote probably fairly square into Alternative 6.3; I don't think 6.1 is useful. Having to tell people to RTFM comes across pretty passive aggressive all the time. Also it's the compiler's knowledge as to what is deprecated or not and it should report this. 6.2 is even worse, as it now has two components that need to be kept in sync, while the extensions are pretty much integral to GHC. Hence GHC has this knowledge and should report it. 6.4 and 6.5 are in the same line as the Legacy/Deprecated extra complexity bucket to me. Again, what's shipped in the stable release _is_ stable to me. And as such any _unstable_ extensions should _not_ be in stable ghc releases. Other languages have separate channels for this. I've also proposed multiple times to have either two separate development branches: stable + experimental (stable being periodically merged into experimental), and cutting _stable_ releases from stable, potentially offering _experimental_ releases from the experimental branch. And alternative model is to have a single branch (as I do understand that getting stuff from the experimental branch migrated into stable could be a bit messy), but have every _unstable_ extension behind a -DEXPERIMENTAL compile time flag. The same flag could be used to produce experimental ghc releases for 3rd parties to consume. Again, my point is that Unstable extensions should _not_ be in the Stable ghc releases, and as such anything that's in the stable ghc releases should be considered stable. If I want to play with bleeding edge features, I should have to use a completely separate compiler for this (again, other languages _do_ follow this approach). And that leaves us with stable extensions in GHC, for which we eventually see that we have better facilities now or learned over time that these extensions (despite being stable), have reached their end of life. In that case they should be marked as deprecated with appropriately long deprecation cycles. GHC already has a ton of flags, let's try not to add that many more to it. Ultimately someone needs to keep all of this in their head, while also trying to get their job done. And for some this job is 9-5, five days a week only; no late night hacking sessions, no weekend projects; but instead soccer practice, cycling, spending time with their family. If we want to make haskell successful, we need to make sure that in that people can be effective and productive and solve real world problems in the 40hs they have per week; and not study manuals, or flags (and if they see one of the many unknown flags, go study those flags) more than absolutely necessary to get work done. In summary, I don't see myself supporting this proposal as it adds too much complexity and sets in stone that unstable extensions are part of a stable compiler. I'm happy to see that the "only deprecations" option is listed as an alternative in 6.3, even though I do not agree with the assessment that we need more nuance for users. Extension in my opinion should only be stable, or deprecated. And the end user should never see unstable extensions, unless they _explicitly_ asked for an experimental/unstable compiler. Moritz On Sat, 2 Sept 2023 at 08:24, Eric Seidel mailto:eric@seidel.io> wrote: There's a non-normative and a normative component to this proposal. The non-normative piece says that there should be a categorization scheme for language extensions. That is inarguable in my opinion. The proposal also suggests an initial framework of four categories, which seems like a reasonable place to start. (Vlad says we should first figure out how to map all extensions to the categories; I disagree. We can iterate on the categories over time, as needed.) The normative piece of the proposal says that we should start warning on the use of any Deprecated, Unstable, or Legacy extensions. This seems like a reasonable ideal, but the practicality kind of hinges on the bucketing of specific extensions (and on Richard's question of how `default-language` is interpreted). The authors give some recommendations of how to bucket particular extensions, but it's not exhaustive and I also view it as the authors' desire rather than a specific commitment of the proposal. So in my view: * Yes, we should have a framework for categorizing the jungle of language extensions, and the proposal seems like a fine starting point. * Yes, we should have a set of warnings for users who would like to forbid certain categories of extensions. * We should probably defer any decisions about default enablement of warnings until we have a complete proposed categorization. And that discussion should include some analysis of the pervasiveness of "deprecated", "unstable", and "legacy" extensions so we can judge the amount of churn. Just like any other discussion about deprecation. Eric On Fri, Sep 1, 2023, at 12:56, Richard Eisenberg wrote: > I've just posted on the GitHub ticket. I remain against the proposal in > its current form, mostly because it means (if I understand correctly) > that everyone who says `default-language: Haskell2010` will get > warnings. > > Richard > >> On Sep 1, 2023, at 12:21 PM, Simon Marlow mailto:marlowsd@gmail.com> wrote: >> >> On Fri, 1 Sept 2023 at 17:17, Simon Marlow mailto:marlowsd@gmail.com> wrote: >>> A few things make this not a straightforward thumbs up for me, though I'm not strongly against. >>> >>> What is the interaction with GHC20xx? Presumably we want to say something like GHC20xx will never include any Deprecated or Legacy extensions? What about Unsable? if an extension transitions from Stable -> Legacy, would we remove it from the next GHC20xx? >> >> Ah, I just noticed that the proposal does say something about this: >> >>> For existing, or future, language sets such as `GHC2021` or `Haskell98`, it is expected that none of the contained extensions would be `Unstable`. However, this proposal does not seek to impose any particular policy on the inclusion of extensions into language sets - the developers and the steering committee are always in the best position to make a decision about a concrete extension and extension set. >> >> OK. >> >> Simon >> >> >>> >>> Something doesn't feel quite right about the warning system. If a module can start with >>> >>> {-# OPTIONS_GHC -Wno-XDeprecated #-} >>> {-# LANGUAGE OverlappingInstances #-} >>> >>> and silently use an extension that the {build system, user, project} wanted to disallow, have we achieved anything? Compare this to the current situation, where the environment can say -XNoOverlappingInstances and code can override that with {-# LANGUAGE OverlappingInstances #-} - there's essentially no difference, we just added another layer of disable/override that isn't buying us anything. >>> >>> (note I'm viewing this through the spectacles of -Werror, because I've come to believe that warnings are essentially not useful unless given teeth with -Werror.) >>> >>> Cheers >>> Simon >>> >>> On Fri, 1 Sept 2023 at 13:18, Vladislav Zavialov mailto:vlad.z.4096@gmail.com> wrote: >>>> I agree that we need a categorisation of extension language flags, but I'm not convinced that {Stable, Unstable, Deprecated, Legacy} is the right set of labels. In fact, I wouldn't want to commit to any particular categorisation before we actually go through all the extensions in GHC and see for ourselves that they can be adequately categorized according to the proposed system. >>>> >>>> The proposal says "classifications of individual language extensions will be left to a future proposal". Well, I am skeptical that this separation makes sense. I would much prefer if we were discussing a concrete categorisation proposal, not just a set of four labels whose implications I can't fully grasp. >>>> >>>> Vlad >>>> >>>> On Fri, Sep 1, 2023 at 11:37 AM Simon Peyton Jones mailto:simon.peytonjones@gmail.com> wrote: >>>>> Dear Simon, Vlad, Eric, Chris, Moritz >>>>> >>>>> I would love to hear from you about this proposal. *Please*. >>>>> >>>>> I plan to accept it unless I hear dissent. But I would much rather have an explicit response from you than take silence as assent. You are a member of the committee, after all! >>>>> >>>>> My apologies if I have missed your reply >>>>> >>>>> Simon

-- 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

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