[ghc-steering-committee] #380 GHC2021: Current status
Joachim Breitner
mail at joachim-breitner.de
Fri Dec 4 11:24:01 UTC 2020
Hi,
Am Freitag, den 04.12.2020, 11:07 +0000 schrieb Tom Harding:
> After all, the introduction of this extension won’t break any
> existing code (because it won’t be enabled) and it’s probably best to
> steer people (very gently) away from * ~ Type.
>
> This decision obviously hinges on a couple of assumptions, and maybe
> this is a controversial opinion, but I don’t think it’s necessarily a
> bad thing to include this, even though it disagrees with the
> Haskell2010 spec.
I strongly disagree. The goal of GHC2021 is, in my book, _not_ to
change peoples behavior, and should only include uncontroversial,
harmless extensions. Note that we want this to be the _default_ mode of
GHC as well, so it may break existing non-cabalized scripts.
So why getting people away from expecting and writing * may be a
laudible goal, I’d be rather hesitant to use _this_ tool to achieve
that. At least not without exposing Type in the prelude:
Prelude> :set -XKindSignatures
Prelude> :k Maybe
Maybe :: * -> *
Prelude> :k Maybe :: * -> *
Maybe :: * -> * :: * -> *
Prelude> :set -XNoStarIsType
Prelude> :k Maybe
Maybe :: Type -> Type
Prelude> :k Maybe :: Type -> Type
<interactive>:1:10: error:
Not in scope: type constructor or class ‘Type’
<interactive>:1:18: error:
Not in scope: type constructor or class ‘Type’
I find this too much of a _change_ (rather than a bunch of harmless
opt-in extensions and corner case cleanups) to be eligible for GHC2021.
I _could_ get behind a less drastic change, e.g. a -XStarCanBeType
where GHC would by default print things using Type, have Type in scope
by default (or print it with Data.Kind.Type), but also accept * as Type
so that there is a nicer transition period. More careful nudging, less
throat-forcing of this change.
In any case, even if you think that GHC202x is the right tool to
facilitate this change, then I recommend to not do it with GHC2021.
Let's make GHC2021 smooth as butter for anyone, that it gets actually
used with joy by most, and there is no community split because of it!
Then we may have a better stand to carefully make controversial changes
with GHC2022.
Cheers,
Joachim
--
Joachim Breitner
mail at joachim-breitner.de
http://www.joachim-breitner.de/
More information about the ghc-steering-committee
mailing list