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@joachim-breitner.de http://www.joachim-breitner.de/