[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