…perhaps there should be a “Pre-Pre-Pre-HFTP: Decoupling Haskell and GHC” - wait a moment, I think I’m having deja vu:
for most people, “GHC” was synonymous with “Haskell”.
(and yes: I know people can use GHC’s-XHaskell98and-XHaskell2010options - our continual presence here and on other forums would indicate doing that isn’t a viable solution).
So just having “fixed-standard language” command-line options for GHC isn’t enough:
-
presumably there would also have to be Haskell '98, Haskell 2010,
Haskell 2020, etc. standard-compatible versions of most of the major packages in Hackage, and elsewhere; -
separate Hackage '98, Hackage 2010, Hackage [next version] as well as Cabal, Stack, ad infinitum i.e. a self-contained suite of packages and tools [and documentation] for each version of Haskell.
…any volunteers?
I for one like the idea of a new fixed language standard - it’s a proven solution to the documentation problem: that’s why Haskell '98 exists. But the existence of Hackage alone clearly shows that the Haskell ecosystem in 2022 is so much larger than it was back in 1998 - maybe that was one big reason why Haskell 2020 failed, and is certainly a problem for any future attempts at setting a new fixed standard, for both the language and libraries.
As for trying to define a new fixed standard just for the language, all the language extensions now in use across Haskell libraries far and wide would appear to leave future standardisers with a dilemma:
- keep the language relatively compact, and most likely break every library in existence;
- support as many libraries as possible, and most likely end up with a big, bloated language.
If you have any ideas for resolving this predicament, please contact the Haskell Foundation today!