# GHC Steering Committee seeks input from industrial Haskell users

**URL:** <https://discourse.haskell.org/t/ghc-steering-committee-seeks-input-from-industrial-haskell-users/7096>\
**Category:** Haskell Foundation\
**Created:** [July 25, 2023, 3:13pm UTC](https://discourse.haskell.org/t/ghc-steering-committee-seeks-input-from-industrial-haskell-users/7096 "2023-07-25T15:13:19Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![david-christiansen](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/david-christiansen/32/2404_2.png) [@david-christiansen](https://discourse.haskell.org/u/david-christiansen)\
**Post date:** [July 25, 2023, 3:13pm UTC](https://discourse.haskell.org/t/ghc-steering-committee-seeks-input-from-industrial-haskell-users/7096/1 "2023-07-25T15:13:20Z")

</div>

[GHC Proposal #601](https://github.com/ghc-proposals/ghc-proposals/pull/601) proposes a lifecycle for Haskell language extensions and an associated system of compiler warnings. The lifecycle categorizes language extensions as being one of the following:

- An **experimental** extension, subject to rapid evolution (e.g. `LinearTypes`)
- A **mature** extension, to which changes are not expected (e.g. `DeriveFunctor`)
- A **deprecated** extension, which will be removed from an imminent GHC release
- A **legacy** extension, which is generally considered to be a design dead-end but that is not scheduled for removal (e.g. `NPlusKPatterns`)  
The compiler warnings would (configurably) warn about the use of experimental, legacy, or deprecated extensions.

The Haskell Foundation’s Stability Working Group thinks that this can solve a real need: teams of Haskell developers will be able to more easily understand the status of extensions and express machine-checked policies for CI. Furthermore, if an extension changes categories (e.g. moving from “experimental” to “deprecated”), the new warnings on a compiler update will be a good reminder to check the release notes and see what needs to be done.

The GHC Steering Committee is currently evaluating the proposal. [They are interested in feedback from industrial teams](https://github.com/ghc-proposals/ghc-proposals/pull/601#issuecomment-1650011296) - if you’re using Haskell at work, please chime in on the thread, even if your comment is just “Sounds helpful” or “Not relevant to us” (although substantive comments are of course also welcome).

---

<div class="post-metadata">

**Author:** ![HaskellEnthusiast](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/haskellenthusiast/32/3490_2.png) [@HaskellEnthusiast](https://discourse.haskell.org/u/HaskellEnthusiast)\
**Post date:** [July 25, 2023, 3:38pm UTC](https://discourse.haskell.org/t/ghc-steering-committee-seeks-input-from-industrial-haskell-users/7096/2 "2023-07-25T15:38:47Z")

</div>

How is mature defined? Experimental sounds unreliable so one can expect failures but, for instance, was Monad Fail mature or Semigroup changes mature?

---

<div class="post-metadata">

**Author:** ![tomjaguarpaw](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/tomjaguarpaw/32/1230_2.png) [@tomjaguarpaw](https://discourse.haskell.org/u/tomjaguarpaw)\
**Post date:** [July 25, 2023, 3:42pm UTC](https://discourse.haskell.org/t/ghc-steering-committee-seeks-input-from-industrial-haskell-users/7096/3 "2023-07-25T15:42:58Z")

</div>

The Semigroup change wasn’t a language extension, and I don’t think Monad Fail was (I guess it impinged somehow on desugaring but I don’t think it was an extension at any point).

---

<div class="post-metadata">

**Author:** ![david-christiansen](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/david-christiansen/32/2404_2.png) [@david-christiansen](https://discourse.haskell.org/u/david-christiansen)\
**Post date:** [July 25, 2023, 4:51pm UTC](https://discourse.haskell.org/t/ghc-steering-committee-seeks-input-from-industrial-haskell-users/7096/4 "2023-07-25T16:51:45Z")

</div>

> [@HaskellEnthusiast](#):
>
> How is mature defined?

In the [proposal text](https://github.com/david-christiansen/ghc-proposals/blob/extension-lifecycle-proposal/proposals/0000-extension-lifecycle-framework.md#21-categories-and-lifecycle), it’s defined as follows:

> `Mature` extensions are considered to be finished and are not expected to undergo regular changes. These features can be used without worry of unexpected changes, and they are not known to contain serious design or implementation deficiencies. Any breaking change to a mature extension will be announced well in advance of the change being made, with a migration path provided if possible.

As @tomjaguarpaw indicates, neither of those changes were to extensions, so they would not have been impacted by this proposal.

---

<div class="post-metadata">

**Author:** ![david-christiansen](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/david-christiansen/32/2404_2.png) [@david-christiansen](https://discourse.haskell.org/u/david-christiansen)\
**Post date:** [July 26, 2023, 10:27am UTC](https://discourse.haskell.org/t/ghc-steering-committee-seeks-input-from-industrial-haskell-users/7096/6 "2023-07-26T10:27:18Z")

</div>

Thanks! Would you mind putting your comments on the discussion thread for the proposal, so that the committee will see them?

---

<div class="post-metadata">

**Author:** ![mmmyaa](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/mmmyaa/32/3258_2.png) [@mmmyaa](https://discourse.haskell.org/u/mmmyaa)\
**Post date:** [July 26, 2023, 10:47am UTC](https://discourse.haskell.org/t/ghc-steering-committee-seeks-input-from-industrial-haskell-users/7096/8 "2023-07-26T10:47:27Z")

</div>

Realistically, the extension lifecycle should go from experimental-\>stable and that’s it.

If a user uses a stable extension they should expect that it will work out for subsequent releases, even if it becomes legacy or deprecated.

---

<div class="post-metadata">

**Author:** ![hellwolf](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/hellwolf/32/3020_2.png) [@hellwolf](https://discourse.haskell.org/u/hellwolf)\
**Post date:** [July 26, 2023, 11:56am UTC](https://discourse.haskell.org/t/ghc-steering-committee-seeks-input-from-industrial-haskell-users/7096/9 "2023-07-26T11:56:04Z")

</div>

> [@mmmyaa](#):
>
> the extension lifecycle should go from experimental-\>stable and that’s it.

That is the happy path, which in the proposal is experimental → mature. But deprecated & legacy are for sad paths, namely how to scheduling sunsets of some extensions.

---

<div class="post-metadata">

**Author:** ![hellwolf](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/hellwolf/32/3020_2.png) [@hellwolf](https://discourse.haskell.org/u/hellwolf)\
**Post date:** [July 26, 2023, 11:58am UTC](https://discourse.haskell.org/t/ghc-steering-committee-seeks-input-from-industrial-haskell-users/7096/10 "2023-07-26T11:58:36Z")

</div>

> [@maxigit](#):
>
> 1 - can I use this extension with safely, i.e. will it changed or being or removed, in other word “will my code been broken in the future”,

From how I read, “mature” ones have high assurance for you in that matter. “legacy” ones may also work, but it’s also a warning to you that you might want to move away from it.

> [@maxigit](#):
>
> 2 - and to a lesser extend will I be the only one using it, making my code base “harder” to work with by newcommers.

hmm, that’s probably the intention of extension sets: Haskell 98/2010, GHC 2021?

---

<div class="post-metadata">

**Author:** ![mmmyaa](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/mmmyaa/32/3258_2.png) [@mmmyaa](https://discourse.haskell.org/u/mmmyaa)\
**Post date:** [July 26, 2023, 7:10pm UTC](https://discourse.haskell.org/t/ghc-steering-committee-seeks-input-from-industrial-haskell-users/7096/12 "2023-07-26T19:10:05Z")

</div>

To be clearer, what I meant was being legacy or deprecated is a tag associated with the path, and not the path itself. Once it hits mature and users start using it, there should not be any breaking changes even if it goes into legacy or deprecated, which means that these apis should remain there for some defined X versions from the warning until its confirmed that nobody uses it at all (and since this is hard to confirm, in practice this means nothing is removed once it hits mature).

This level of guarantee allows industry users to use what they want safely without fear of needing to dedicate time to refactor something because it has become deprecated. The industry can trust mature extensions are well designed with long lasting semantics.

---

<div class="post-metadata">

**Author:** ![janus](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/janus/32/1060_2.png) [@janus](https://discourse.haskell.org/u/janus)\
**Post date:** [July 26, 2023, 8:36pm UTC](https://discourse.haskell.org/t/ghc-steering-committee-seeks-input-from-industrial-haskell-users/7096/13 "2023-07-26T20:36:22Z")

</div>

There was an extension called [MonadFailDesugaring](https://downloads.haskell.org/~ghc/8.10.7/docs/html/users_guide/glasgow_exts.html#extension-MonadFailDesugaring) which was added in 8.0.1, enabled by default in 8.6.1 and removed in 9.0.1 (I think, can’t find it in the release notes). I suppose it could be considered mature in GHC 8.6.1?

---

<div class="post-metadata">

**Author:** ![andreabedini](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/andreabedini/32/2201_2.png) [@andreabedini](https://discourse.haskell.org/u/andreabedini)\
**Post date:** [July 27, 2023, 12:04am UTC](https://discourse.haskell.org/t/ghc-steering-committee-seeks-input-from-industrial-haskell-users/7096/14 "2023-07-27T00:04:57Z")

</div>

Maybe we could distinguish “superseded” (when there is a new extension that includes the same functionality and there is a clear migration path, like the case of MonadFailDesugaring) and “deprecated” (when the idea is flawed and/or abandoned).

Not sure this helps anyone though.

(I only skimmed the proposal, apologies if this has already been considered or discussed)

---

<div class="post-metadata">

**Author:** ![lrworth](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/lrworth/32/1004_2.png) [@lrworth](https://discourse.haskell.org/u/lrworth)\
**Post date:** [July 29, 2023, 10:10pm UTC](https://discourse.haskell.org/t/ghc-steering-committee-seeks-input-from-industrial-haskell-users/7096/16 "2023-07-29T22:10:31Z")

</div>

My company uses Haskell to deploy web services. I think we find this useful for a couple of reasons:

- we would default to only allowing mature extensions, to avoid future maintenance work. Ideally this could be changed in a per-file and per-package basis, eg if we really wanted to use LinearTypes in one module.
- We would find where we were using deprecated extensions before they were removed, enabling gradual migration away from them.

---

<div class="post-metadata">

**Author:** ![mmmyaa](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/mmmyaa/32/3258_2.png) [@mmmyaa](https://discourse.haskell.org/u/mmmyaa)\
**Post date:** [July 31, 2023, 12:52am UTC](https://discourse.haskell.org/t/ghc-steering-committee-seeks-input-from-industrial-haskell-users/7096/17 "2023-07-31T00:52:46Z")

</div>

You need to be clear to them that this means that mature extensions should not be changed at all or only go into legacy only, not deprecated.

It is not apparent currently that mature extensions wont get removed in future releases.

---

<div class="post-metadata">

**Author:** ![nomeata](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/nomeata/32/1188_2.png) [@nomeata](https://discourse.haskell.org/u/nomeata)\
**Post date:** [July 31, 2023, 7:29am UTC](https://discourse.haskell.org/t/ghc-steering-committee-seeks-input-from-industrial-haskell-users/7096/18 "2023-07-31T07:29:40Z")

</div>

> [@mmmyaa](#):
>
> You need to be clear to them that this means that mature extensions should not be changed at all or only go into legacy only, not deprecated.

I am not sure we want to promise that, and the proposal actually says

> Any breaking change to a mature extension will be announced well in advance of the change being made, with a migration path provided if possible.

If we could predict the future, then maybe we could make an absolute statement, but in light of more information, I hope we can still make any change – with due process. That’s the point of `Deprecated`, isn’t it?

---

<div class="post-metadata">

**Author:** ![mmmyaa](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/mmmyaa/32/3258_2.png) [@mmmyaa](https://discourse.haskell.org/u/mmmyaa)\
**Post date:** [July 31, 2023, 8:43am UTC](https://discourse.haskell.org/t/ghc-steering-committee-seeks-input-from-industrial-haskell-users/7096/19 "2023-07-31T08:43:42Z")

</div>

> I am not sure we want to promise that, and the proposal actually says

If this cannot be promised for certain LTS major or minor versions, as noted above by @maxigit then marking something as “mature” has no difference from being “experimental”. “High assurance” isn’t something that can be quantified or planned for.

> If we could predict the future, then maybe we could make an absolute statement, but in light of more information, I hope we can still make any change – with due process. That’s the point of `Deprecated`, isn’t it?

Languages suitable for wider enterprise adoption often have long-lasting semantics, especially for LTS versions (up to X amount of years), and I believe we can all learn something from the Python 2-\>3 fiasco. This is not about “predicting the future”, this is about committing to stability for a certain amount of time that can be factored into planning and reducing the risk of using Haskell in production.

---

<div class="post-metadata">

**Author:** ![david-christiansen](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/david-christiansen/32/2404_2.png) [@david-christiansen](https://discourse.haskell.org/u/david-christiansen)\
**Post date:** [July 31, 2023, 9:44am UTC](https://discourse.haskell.org/t/ghc-steering-committee-seeks-input-from-industrial-haskell-users/7096/20 "2023-07-31T09:44:47Z")

</div>

Stability commitments are absolutely important.

Today, some extensions are known to be basically “finished”, and considered unlikely to ever change. Others are considered to be unfinished, subject to more or less rapid iteration as the contact with real users casts light on the design. It is highly unlikely that one of these “finished” extensions would be removed or drastically changed, certainly not without a long deprecation cycle. On the other hand, rapid iteration from release to release of a new feature is normal and expected.

How are users to know which is which? This proposal seeks to provide a means by which it can be communicated, and by which changes to that communication can be checked in CI.

I totally get that it doesn’t solve every problem - there are lots of things we can do to improve things! Do you think that this makes things better, though?

---

<div class="post-metadata">

**Author:** ![jaror](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/jaror/32/3271_2.png) [@jaror](https://discourse.haskell.org/u/jaror)\
**Post date:** [July 31, 2023, 11:36am UTC](https://discourse.haskell.org/t/ghc-steering-committee-seeks-input-from-industrial-haskell-users/7096/22 "2023-07-31T11:36:10Z")

</div>

(Disclaimer: I’m not an industrial user)

> [@maxigit](#):
>
> I’ve never seen any extension, experimental or not being changed or removed.

`RankNTypes` was infamously changed recently which broke a whole lot of code and spawned the new `DeepSubsumption` extension that undoes the change. Also, `ExistentialQuantification` has changed and will probably soon change again, see [the other thread](http://discourse.haskell.org/t/anybody-using-ghc2021/7095/21) (that is a rather trivial change, but it could break code).

> [@maxigit](#):
>
> we could think that once it’s been stabilised it actually becomes the default and the extension becomes “obsoletes”

`GHC2021` has become the default. Removing old extensions just breaks existing code for little reason. I guess you could argue it would improve discoverability of the remaining extensions, but that doesn’t weigh up against the breakage it would cause; the categorisation proposed here would be a better way to improve discoverability in my opinion.

---

<div class="post-metadata">

**Author:** ![nomeata](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/nomeata/32/1188_2.png) [@nomeata](https://discourse.haskell.org/u/nomeata)\
**Post date:** [July 31, 2023, 9:12pm UTC](https://discourse.haskell.org/t/ghc-steering-committee-seeks-input-from-industrial-haskell-users/7096/24 "2023-07-31T21:12:27Z")

</div>

> [@maxigit](#):
>
> What I mean by remove is when an extension is _adopted_ the doc could me moved the corresponding part in the syntax manual and the fact that it used to be an extension all forgotten. So that when you looked at Haskell 2010 for example you have a standalone thing, not Haskell 98 + x y and z.

I agree. I hope we will get to the point where the latest GHC20xx is perceived not as a set of extensions, but as a wholesome language edition, and the documentation structure hopefully will support that.

The old editions (Haskell2010, GHC2021, all the various extensions _to_ these base lines) may still be supported to not break code lying around untouched. But hopefully developers who write fresh code, or who keep following the GHC20xx language editions with their actively maintained code, will no long have to think of so many extensions as features.

---

<div class="post-metadata">

**Author:** ![AntC2](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/antc2/32/1872_2.png) [@AntC2](https://discourse.haskell.org/u/AntC2)\
**Post date:** [July 31, 2023, 9:41pm UTC](https://discourse.haskell.org/t/ghc-steering-committee-seeks-input-from-industrial-haskell-users/7096/25 "2023-07-31T21:41:12Z")

</div>

> [@maxigit](#):
>
> I’ve never seen any extension, experimental or not being changed or removed.

[`DatatypeContexts`](https://downloads.haskell.org/ghc/latest/docs/users_guide/exts/datatype_contexts.html) was removed by GHC2010 – chiefly so that we could experiment with bringing back the syntax but with more helpful semantics.

The current extensions around [`DuplicateRecordFields`/Disambiguation and friends](https://downloads.haskell.org/ghc/latest/docs/users_guide/exts/duplicate_record_fields.html) are regarded as experimental and liable to change. (That is, some of the implementation detail might change, not the proposed syntax: the implementation has run into some fishhooks.) And amongst the ‘friends’, [`NoFieldSelectors`](https://downloads.haskell.org/ghc/latest/docs/users_guide/exts/field_selectors.html) takes away a H98 feature.

> [@](#):
>
> Nothing get ever removed from GHC

Not true looking back over ~25 years; but I agree GHC has been getting more timid over the past (say) 5 years. Since `DatatypeContexts` is still ‘on the books’, there’s a risk someone’s still using it, so can we actually introduce something more helpful under that name?

> [@](#):
>
> I might not count as a _industrial_ user.

Yeah. I’m pretty sure David’s o.p. wasn’t aimed at me (as a hobby user), so I’ve kept off this thread.

---

<div class="post-metadata">

**Author:** ![david-christiansen](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/david-christiansen/32/2404_2.png) [@david-christiansen](https://discourse.haskell.org/u/david-christiansen)\
**Post date:** [August 1, 2023, 7:35am UTC](https://discourse.haskell.org/t/ghc-steering-committee-seeks-input-from-industrial-haskell-users/7096/26 "2023-08-01T07:35:54Z")

</div>

> [@AntC2](#):
>
> Yeah. I’m pretty sure David’s o.p. wasn’t aimed at me (as a hobby user), so I’ve kept off this thread.

That’s right - this proposal was written specifically to address challenges we’d heard of from larger teams with mixed levels of Haskell expertise. If it helps enough of them significantly and doesn’t impose unacceptable costs on hobbyists, researchers, enthusiasts, and teams of experts, then I think it’s a win - if not, then back to the drawing board!