Could GHC remove old extensions?

[atravers]

@santiweight

Could GHC remove old extensions [by enabling them permanently in the language]?

Ah, the joys of a single [mainstream]-implementation language: would this topic have even been brought up if there was a second and comparable Haskell implementation…

@santiweight

I don’t want to get into a discussion about [e.g.] whether DeriveFunctor (or some other extension) should be removed - I am only asking whether or not they can be removed.

…a very salient qualification. I believe the main issue with making a language extension permanent is the potential conflict with other such extensions - at the risk of being repetitive:

• if there are N extensions, then there are at least 2^N combinations of those extensions;
• not all of those combinations work in GHC.

Just because you’ve been using your favourite set of extensions for years doesn’t mean they will automatically qualify for permanent inclusion - perhaps the best option now is for some related extensions to somehow be merged together. As for another GHC2021-style compendium e.g. GHC2024…finding another sufficiently-large-and-useful combination of extensions that don’t cause conflicts elsewhere will only increase in difficulty.

@Kleidukos

I too would like to see some extensions part of the language, but this needs a new language.

…or a new language version in which they can be stabilised - the HF Stability Working Group might be able to provide some guidance here (if they have time to spare).

@santiweight

Out of curiosity, are there other implementations of Haskell that are industrial strength? […] I often see this idea that Haskell is not GHC - but on the other hand, this “non-GHC Haskell” doesn’t appear to exist - who maintains “Haskell”, how can one make proposed language changes?

Unless I’m badly mistaken, I thought that was now the purview of the HF.

@Kleidukos

[…] without a standard it’s very difficult to offer alternative implementations.

…as the current effort to port Rust to GCC clearly shows. In contrast, Prolog has its own ISO standard (parts 1 and 2) and several mature implementations.

Currently there are two relatively well-known non-strict typed languages: Miranda^(R) and Haskell; both now being single-implementation languages and having small user bases (Miranda^(R) in education, Haskell tending more towards production) - is that a coincidence?

In an alternate reality where non-strict languages are in the majority, not having a language standard may not be such a hindrance. But in this reality, being non-strict is hard work, which must surely make the task of building another implementation for either language even more difficult in the absence of well-specified language standards.