<div dir="ltr"><div>I would like to urge us not to include NoStarIsType in the defaults until we include StandaloneKindSignature as well. Mostly on aesthetic grounds.</div><div><br></div><div>It's fairly obvious that NoStarIsType will be the default eventually. I just think that GHC2021 is premature.<br></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Dec 4, 2020 at 1:09 PM Simon Peyton Jones via ghc-steering-committee <<a href="mailto:ghc-steering-committee@haskell.org">ghc-steering-committee@haskell.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">| that. At least not without exposing Type in the prelude<br>
<br>
I'm often annoyed by the need to import Data.Kind(Type). Exposing Type from the Prelude might be just the right thing.<br>
<br>
Simon<br>
<br>
| -----Original Message-----<br>
| From: ghc-steering-committee <ghc-steering-committee-<br>
| <a href="mailto:bounces@haskell.org" target="_blank">bounces@haskell.org</a>> On Behalf Of Joachim Breitner<br>
| Sent: 04 December 2020 11:24<br>
| To: <a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
| Subject: Re: [ghc-steering-committee] #380 GHC2021: Current status<br>
| <br>
| Hi,<br>
| <br>
| Am Freitag, den 04.12.2020, 11:07 +0000 schrieb Tom Harding:<br>
| > After all, the introduction of this extension won’t break any<br>
| existing<br>
| > code (because it won’t be enabled) and it’s probably best to steer<br>
| > people (very gently) away from * ~ Type.<br>
| ><br>
| > This decision obviously hinges on a couple of assumptions, and maybe<br>
| > this is a controversial opinion, but I don’t think it’s necessarily<br>
| a<br>
| > bad thing to include this, even though it disagrees with the<br>
| > Haskell2010 spec.<br>
| <br>
| I strongly disagree. The goal of GHC2021 is, in my book, _not_ to<br>
| change peoples behavior, and should only include uncontroversial,<br>
| harmless extensions. Note that we want this to be the _default_ mode<br>
| of GHC as well, so it may break existing non-cabalized scripts.<br>
| <br>
| So why getting people away from expecting and writing * may be a<br>
| laudible goal, I’d be rather hesitant to use _this_ tool to achieve<br>
| that. At least not without exposing Type in the prelude:<br>
| <br>
| Prelude> :set -XKindSignatures<br>
| Prelude> :k Maybe<br>
| Maybe :: * -> *<br>
| Prelude> :k Maybe :: * -> *<br>
| Maybe :: * -> * :: * -> *<br>
| <br>
| Prelude> :set -XNoStarIsType<br>
| Prelude> :k Maybe<br>
| Maybe :: Type -> Type<br>
| Prelude> :k Maybe :: Type -> Type<br>
| <br>
| <interactive>:1:10: error:<br>
| Not in scope: type constructor or class ‘Type’<br>
| <br>
| <interactive>:1:18: error:<br>
| Not in scope: type constructor or class ‘Type’<br>
| <br>
| I find this too much of a _change_ (rather than a bunch of harmless<br>
| opt-in extensions and corner case cleanups) to be eligible for<br>
| GHC2021.<br>
| <br>
| <br>
| I _could_ get behind a less drastic change, e.g. a -XStarCanBeType<br>
| where GHC would by default print things using Type, have Type in<br>
| scope<br>
| by default (or print it with Data.Kind.Type), but also accept * as<br>
| Type<br>
| so that there is a nicer transition period. More careful nudging,<br>
| less<br>
| throat-forcing of this change.<br>
| <br>
| <br>
| In any case, even if you think that GHC202x is the right tool to<br>
| facilitate this change, then I recommend to not do it with GHC2021.<br>
| Let's make GHC2021 smooth as butter for anyone, that it gets<br>
| actually<br>
| used with joy by most, and there is no community split because of<br>
| it!<br>
| <br>
| Then we may have a better stand to carefully make controversial<br>
| changes<br>
| with GHC2022.<br>
| <br>
| Cheers,<br>
| Joachim<br>
| <br>
| --<br>
| Joachim Breitner<br>
| <a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a><br>
| <br>
| <a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j" rel="noreferrer" target="_blank">https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j</a><br>
| oachim-<br>
| <a href="http://breitner.de" rel="noreferrer" target="_blank">breitner.de</a>%2F&data=04%7C01%7Csimonpj%<a href="http://40microsoft.com" rel="noreferrer" target="_blank">40microsoft.com</a>%7C71fd2da218<br>
| 274565766708d8984726bd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C63<br>
| 7426779203482378%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV<br>
| 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=al%2FPwBdOBMsmI<br>
| v%2F7hH3ce%2BdPCKa9K6e%2BMtfRs2vteaY%3D&reserved=0<br>
| <br>
| <br>
| _______________________________________________<br>
| ghc-steering-committee mailing list<br>
| <a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
| <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail" rel="noreferrer" target="_blank">https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail</a><br>
| .<a href="http://haskell.org" rel="noreferrer" target="_blank">haskell.org</a>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-<br>
| committee&data=04%7C01%7Csimonpj%<a href="http://40microsoft.com" rel="noreferrer" target="_blank">40microsoft.com</a>%7C71fd2da21827456<br>
| 5766708d8984726bd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C6374267<br>
| 79203482378%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz<br>
| IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=DvDb4rRCvnRN%2BcqM4E<br>
| QSIf8kSXNypMnD6PZANjCENQI%3D&reserved=0<br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>