Hi, good input! Am Freitag, dem 07.07.2023 um 09:43 +0200 schrieb Arnaud Spiwack:
What I'm reading is that most respondents seem to believe that when an extension becomes part of GHC20xx, it should be removed (with a deprecation period, I'd imagine): if you want the feature, use GHC20xx.
TL;DR: Yes, if “remove” means “remove from sight from developers working on “modern” code; but not when compiling “old” code. this indeed sounds surprisingly hard, and it may depend on what “removes” mean. I do believe that the 2^n complexity is hurting us. But I also do believe that not being to compile old code with new compilers is hurting us. So on the one hand I hope that in a hopefully not so distant future, nobody on up-to-day code will even have to know that -XDeriveFunctor was a thing. It should just work by default. The documentation should frame it as a “normal” feature, not an “extension”. And if the compiler encounters a Haskell2010 module that tries to derive Functor, it should probably indeed suggest “please use GHC20xx”. On the other hand, as long as we can afford the engineering effort, we can keep supporting Haskell98+DeriveFunctor, so that existing code keeps working. This already helps a bit fighting the 2^n mental complexity, because the set of extensions a (non-archaeological) developer encounters is smaller. It further help with the 2^n implementation complexity if we’d say * Old extensions cannot be turned off. So if you have choose LANGAUGE GHC2024 as the language edition, you simply don’t get to select -XNoDeriveFunctor. (Maybe we offer _warnings_ if people want help avoiding some feature.) * New extensions can only be used with new based editions. If we get add -XFuzzyTypes next year, this feature is only available in modules that have GHC2024 as the base language edition This means, for example, that nobody has to worry about the interaction between FuzzyTypes with NoDeriveFunctor, and the 2^n explosion gets better. (I think this is very close to what you are saying?) Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/