[ghc-steering-committee] #380 GHC2021: Current status

[Eric Seidel]

I also did not realize that GHC2021 was going to become the default behavior, and will change my vote against StarIsType. 

Is the expectation that GHC2021 remains the new default behavior, or will GHC2022 replace it as the default? I ask because tying these standards to GHC’s default behavior will make it much harder to correct mistakes or migrate to new designs of extensions (eg LambdaCase). Requiring an explicit opt-in to a GHC20XX standard means that users can upgrade to a new compiler and adapt to the new standard separately, which is very useful in larger enterprises. 

Sent from my iPhone

> On Dec 4, 2020, at 06:30, Tom Harding <tomjharding at live.co.uk> wrote:
> 
> Ah, I see!
> 
> In which case, I wholly agree with you and Alejandro, and I’ll change my vote to a no - I had misunderstood this in my head as just being a more concise way to turn on a lot of extensions, rather than being a deliberate default that we intended to set for GHC. If new users would have to enable NoGHC2021 to get back to The Old Ways, then yes, it’s probably best not to contradict any of the current Haskell2010 defaults.
> 
> Thanks!
> Tom
> 
>> On 4 Dec 2020, at 11:24, Joachim Breitner <mail at joachim-breitner.de> wrote:
>> 
>> 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/
>> 
>> 
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee