<div dir="ltr"><div>Yeah, I'd just hesitate to turn it off by default, because GHC seems much saner overall with PolyKinds on, at least in my experience. It may depend on which packages/libraries you're often importing. I have a feeling that the cases crop up when you import something that was defined using PolyKinds, but your module is not compiled with PolyKinds and GHC then fails to unify and then prints some nonsense that struggles to avoid mentioning the polymorphically-kinded reality of things (iirc, it's even said things along the lines of that it couldn't match type Foo with Foo). I don't have an example handy right at the moment, but I've run into them often enough in practice to recommend people just turn the extension on.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 5 Jul 2022 at 23:58, Chris Dornan <<a href="mailto:chris@chrisdornan.com">chris@chrisdornan.com</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"><div style="overflow-wrap: break-word;">That speaks to why PolyKinds is needed in the long run. I don’t doubt that! (Especially after this report.)<div><br></div><div>My point is merely that PolyKinds is disruptive, and that is likely to undermine confidence in the default Haskell that GHC accepts — really the reverse of what we were hoping to achieve with the new standard configuration.</div><div><br></div><div>Chris<br><div><br></div><div><br><div><br><blockquote type="cite"><div>On 6 Jul 2022, at 04:51, Cale Gibbard <<a href="mailto:cgibbard@gmail.com" target="_blank">cgibbard@gmail.com</a>> wrote:</div><br><div><div dir="ltr">I can remember quite a few times where GHC presented me with an incomprehensible and confused-sounding error message, but then the actual problem was that PolyKinds was off, and upon turning it on, there was no longer any problem -- it's to the point that enabling PolyKinds is one of the first things I try if I find myself disagreeing with GHC on whether something typechecks.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 5 Jul 2022 at 23:46, Chris Dornan <<a href="mailto:chris@chrisdornan.com" target="_blank">chris@chrisdornan.com</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"><div><span style="font-size:19px">I think we can learn to write code for PolyKinds in time, but in my experience it is quite disruptive right now, and could sow FUD around the new consensus we are trying to build.</span><div><span style="font-size:19px"><br></span></div><div><span style="font-size:19px">My inclination would be to revert to Haskell2010 as the default for GHC until we can build confidence around a configuration that we are confident won’t be disruptive.</span></div><div><span style="font-size:19px"><br></span></div><div><span style="font-size:19px">At a minimum I would create ghc2022 = ghc2021 \  {PolyKinds} and make that the default for ghc-9.4.</span></div><div><span style="font-size:19px"><br></span></div><div><span style="font-size:19px">What do y’all think?</span></div><div><span style="font-size:19px"><br></span></div><div><span style="font-size:19px"><br></span><div><br><blockquote type="cite"><div>On 5 Jul 2022, at 16:02, Richard Eisenberg <<a href="mailto:lists@richarde.dev" target="_blank">lists@richarde.dev</a>> wrote:</div><br><div><div>I find that surprising, and disappointing. I think of PolyKinds as largely innocuous, except in strange scenarios, which is why PolyKinds is included in GHC2021. If that is wrong, perhaps we should consider not including PolyKinds in GHC2023...<div><br></div><div>It would be interesting to learn more about what's going wrong.</div><div><br></div><div>Richard<br><div><br><blockquote type="cite"><div>On Jul 5, 2022, at 10:26 AM, Chris Dornan <<a href="mailto:chris@chrisdornan.com" target="_blank">chris@chrisdornan.com</a>> wrote:</div><br><div><div dir="auto">yup, i should have started there—all my recent troubles have come from PolyKinds!</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 5 Jul 2022 at 15:00, Richard Eisenberg <<a href="mailto:lists@richarde.dev" target="_blank">lists@richarde.dev</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">This is PolyKinds, which generalizes the kind of D, meaning that satisfying the Typeable a superclass constraint of C also requires a Typeable k constraint, where (a :: k).<br>
<br>
Richard<br>
<br>
> On Jul 2, 2022, at 12:49 AM, Chris Dornan <<a href="mailto:chris@chrisdornan.com" target="_blank">chris@chrisdornan.com</a>> wrote:<br>
> <br>
> Quick quiz: the below Haskell2010 ‘Phantoms' module (also in this Gist: <a href="https://gist.github.com/cdornan/f75cd8024434d998c87610cbb7fb6ab3" rel="noreferrer" target="_blank">https://gist.github.com/cdornan/f75cd8024434d998c87610cbb7fb6ab3</a>) appears (for me on GHC 9.2.2 and 9.2.3) to not be a GHC2021 module, reporting this error under the latter configuration:<br>
> <br>
> Phantoms.hs:22:10: error:<br>
>    • Could not deduce (Typeable k)<br>
>        arising from the superclasses of an instance declaration<br>
>      from the context: (C a, Typeable a)<br>
>        bound by the instance declaration<br>
>        at Phantoms.hs:22:10-36<br>
>    • In the instance declaration for ‘S (D a)’<br>
>   |<br>
> 22 | instance (C a,Typeable a) => S (D a) where smethod = undefined<br>
>   |          ^^^^^^^^^^^^^^^^^^^^^^^^^^^<br>
> <br>
> Phantoms.hs:22:10: error:<br>
>    • Could not deduce (Typeable k)<br>
>        arising from the superclasses of an instance declaration<br>
>      from the context: (C a, Typeable a)<br>
>        bound by the instance declaration<br>
>        at Phantoms.hs:22:10-36<br>
>    • In the instance declaration for ‘S (D a)’<br>
>   |<br>
> 22 | instance (C a,Typeable a) => S (D a) where smethod = undefined<br>
> <br>
> The question is which language extension(s) are giving rise to these errors?<br>
> <br>
> The ‘Phantoms' module is this:<br>
> <br>
> {-# LANGUAGE DerivingVia #-}<br>
> <br>
> module Phantoms where<br>
> <br>
> import Data.Typeable<br>
> <br>
> <br>
> class C a where<br>
>  cmethod :: Proxy a -> ()<br>
> <br>
> class (Show a, Typeable a) => S a where<br>
>  smethod :: a -> Int<br>
> <br>
> <br>
> newtype UsingD a = UsingD { getUsingD :: a }<br>
> <br>
> <br>
> newtype D a = D { getD :: Int }<br>
>    deriving (Show) via UsingD (D a)<br>
> <br>
> <br>
> instance (C a,Typeable a) => S (D a) where smethod = undefined<br>
> <br>
> instance (C a,Typeable a) => Show (UsingD a) where showsPrec = undefined<br>
> <br>
> <br>
> instance (C a) => C (D a) where cmethod _ = undefined<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://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>
<br>
</blockquote></div></div>
</div></blockquote></div><br></div></div></div></blockquote></div><br></div></div>_______________________________________________<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>
</div></blockquote></div><br></div></div></div></blockquote></div>