[ghc-steering-committee] Language Extension Policy – Round 3
Joachim Breitner
mail at joachim-breitner.de
Sat Jul 8 12:34:04 UTC 2023
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 at joachim-breitner.de
http://www.joachim-breitner.de/
More information about the ghc-steering-committee
mailing list