From chris at chrisdornan.com Sat Jul 2 04:49:00 2022 From: chris at chrisdornan.com (Chris Dornan) Date: Sat, 2 Jul 2022 05:49:00 +0100 Subject: [ghc-steering-committee] Mind the gap Message-ID: <782F2059-9DD6-4D10-8D02-D08FF0C8E314@chrisdornan.com> Quick quiz: the below Haskell2010 ‘Phantoms' module (also in this Gist: https://gist.github.com/cdornan/f75cd8024434d998c87610cbb7fb6ab3) 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: Phantoms.hs:22:10: error: • Could not deduce (Typeable k) arising from the superclasses of an instance declaration from the context: (C a, Typeable a) bound by the instance declaration at Phantoms.hs:22:10-36 • In the instance declaration for ‘S (D a)’ | 22 | instance (C a,Typeable a) => S (D a) where smethod = undefined | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ Phantoms.hs:22:10: error: • Could not deduce (Typeable k) arising from the superclasses of an instance declaration from the context: (C a, Typeable a) bound by the instance declaration at Phantoms.hs:22:10-36 • In the instance declaration for ‘S (D a)’ | 22 | instance (C a,Typeable a) => S (D a) where smethod = undefined The question is which language extension(s) are giving rise to these errors? The ‘Phantoms' module is this: {-# LANGUAGE DerivingVia #-} module Phantoms where import Data.Typeable class C a where cmethod :: Proxy a -> () class (Show a, Typeable a) => S a where smethod :: a -> Int newtype UsingD a = UsingD { getUsingD :: a } newtype D a = D { getD :: Int } deriving (Show) via UsingD (D a) instance (C a,Typeable a) => S (D a) where smethod = undefined instance (C a,Typeable a) => Show (UsingD a) where showsPrec = undefined instance (C a) => C (D a) where cmethod _ = undefined From simon.peytonjones at gmail.com Mon Jul 4 16:42:21 2022 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Mon, 4 Jul 2022 17:42:21 +0100 Subject: [ghc-steering-committee] Modern Scoped Type Variables #448: recommendation (mostly) accept In-Reply-To: References: Message-ID: Arnaud We've had this "Scoped type variables" proposal on our table for too long. Is there anything stopping us from making a decision? Simon On Tue, 29 Mar 2022 at 16:02, Spiwack, Arnaud wrote: > Dear all, > > Let me bring to your attention the Modern Scoped Type Variables proposal, > by our own Richard https://github.com/ghc-proposals/ghc-proposals/pull/448 > . > > The proposal is a touch intimidating, because the text is large. But most > of it comes from other, already accepted, proposals that this proposal is > tidying up and tying together. > > What this proposal tries to achieve is to make a consistent text about all > the recent changes to binding type variables. > > The proposal adds new principles to the `principles.rst` files which > inform the changes proposed, of these, I have the following comments: > - The Visibility Orthogonality Principle doesn't seem to have a very > clear definition. It may be a sign that it's not something that is so > important > - The Explicit Binding Principle says that we need to be able to enforce > that all type variables have a binding site. I think it's a bit strong: I > would like Haskell to let me write a binding site for every type variable, > but not necessarily to error out when that doesn't happen. That being said, > I'm happy with warnings to help me along the way, but I don't think that > this Explicit Binding Principle should be phrased in a way that requires > adding extensions to control this behaviour. > - The Contiguous Scoping Principle, which states that a binder binds in > one contiguous region sounds dubious to me. I don't see a particular reason > for this to be. > > --- > > In the proposed changes themselves: up to Section 5, the proposed changes > are mostly existing accepted proposals, cleaned up with what was learnt > since they were written, as well as to adhere to the new principles. > > These are mostly uncontroversial and the specification makes sense to me. > I'm in favour of accepting all that. > > With the caveat that this proposal introduces quite a few extensions. And > at this point, I'm still not quite sure what Richard recommends is the set > of extensions that I should use (and I'm slightly dismayed that I believe > that it will be a set of cardinal more than 1). I think this reflects a > vision of extensions as switches to customise the behaviour of GHC. This > vision, as I've stated before, is very alien to me: I see extensions as > staging areas for features to become an integral part of Haskell. So I > don't know what to think of all these extensions. I'm definitely not > against splitting -XScopedTypeVariables into smaller components, if it is > done so that they are reassembled in a different way in an alternative > extension that would now be the recommended default (or at least is to > become the next recommended default). > > Finally, there are Sections 6 to 8. These are entirely new. Though they > are working towards the new principles (well, as far as I can tell, Section > 6 doesn't contribute to the principles, but it is a stepping stone for both > Sections 7 and 8). These sections are concerned with adding local > let-bindings of type variables, in particular inside types and patterns. > > By the way, Section 7 proposes two syntaxes for let binders in patterns, > and I *strongly* prefer the second syntax, which reads something like `f > (let b = Bool) (True :: Bool) = …`. > > Anyway, these are new, I feel that they are a bit out of place in a > proposal that is about tidying up the existing designs. That being said, > they are here, and they seem like fairly uncontroversial to me, (except, > probably the syntax `(let b = _)` to bind a variable to a type to be filled > by the compiler). I'm fine with accepting these, though they may require a > bit more scrutiny than the rest. > > Best, > Arnaud > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.spiwack at tweag.io Tue Jul 5 06:58:15 2022 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Tue, 5 Jul 2022 08:58:15 +0200 Subject: [ghc-steering-committee] Modern Scoped Type Variables #448: recommendation (mostly) accept In-Reply-To: References: Message-ID: Yes, we did. And that's largely on me: I got lost in the debates. Reading back, my feeling is that: there is broad agreement on the proposed changes, as long as we move the “let” bits to another proposal (they have barely been discussed anyway). There are discussions on the precise meaning and wording of the principles (as far as I'm aware, I am the only one that questions the existence of one of the principle (the Contiguous Scoping Principle), there is a discussion on whether the Local Lexical Scoping Principle and the Explicit Binding Principle are really to be distinct. Considering all this, I think that the best move is to accept the proposal, as soon as the “let”-related changes have been removed from the proposal. If the wording or details of the principles turn out to need tuning, we can always amend in a future proposal. Richard, do you agree? /Arnaud On Mon, Jul 4, 2022 at 6:41 PM Simon Peyton Jones < simon.peytonjones at gmail.com> wrote: > Arnaud > > We've had this "Scoped type variables" proposal on our table for too > long. Is there anything stopping us from making a decision? > > Simon > > On Tue, 29 Mar 2022 at 16:02, Spiwack, Arnaud > wrote: > >> Dear all, >> >> Let me bring to your attention the Modern Scoped Type Variables proposal, >> by our own Richard >> https://github.com/ghc-proposals/ghc-proposals/pull/448 . >> >> The proposal is a touch intimidating, because the text is large. But most >> of it comes from other, already accepted, proposals that this proposal is >> tidying up and tying together. >> >> What this proposal tries to achieve is to make a consistent text about >> all the recent changes to binding type variables. >> >> The proposal adds new principles to the `principles.rst` files which >> inform the changes proposed, of these, I have the following comments: >> - The Visibility Orthogonality Principle doesn't seem to have a very >> clear definition. It may be a sign that it's not something that is so >> important >> - The Explicit Binding Principle says that we need to be able to enforce >> that all type variables have a binding site. I think it's a bit strong: I >> would like Haskell to let me write a binding site for every type variable, >> but not necessarily to error out when that doesn't happen. That being said, >> I'm happy with warnings to help me along the way, but I don't think that >> this Explicit Binding Principle should be phrased in a way that requires >> adding extensions to control this behaviour. >> - The Contiguous Scoping Principle, which states that a binder binds in >> one contiguous region sounds dubious to me. I don't see a particular reason >> for this to be. >> >> --- >> >> In the proposed changes themselves: up to Section 5, the proposed changes >> are mostly existing accepted proposals, cleaned up with what was learnt >> since they were written, as well as to adhere to the new principles. >> >> These are mostly uncontroversial and the specification makes sense to me. >> I'm in favour of accepting all that. >> >> With the caveat that this proposal introduces quite a few extensions. And >> at this point, I'm still not quite sure what Richard recommends is the set >> of extensions that I should use (and I'm slightly dismayed that I believe >> that it will be a set of cardinal more than 1). I think this reflects a >> vision of extensions as switches to customise the behaviour of GHC. This >> vision, as I've stated before, is very alien to me: I see extensions as >> staging areas for features to become an integral part of Haskell. So I >> don't know what to think of all these extensions. I'm definitely not >> against splitting -XScopedTypeVariables into smaller components, if it is >> done so that they are reassembled in a different way in an alternative >> extension that would now be the recommended default (or at least is to >> become the next recommended default). >> >> Finally, there are Sections 6 to 8. These are entirely new. Though they >> are working towards the new principles (well, as far as I can tell, Section >> 6 doesn't contribute to the principles, but it is a stepping stone for both >> Sections 7 and 8). These sections are concerned with adding local >> let-bindings of type variables, in particular inside types and patterns. >> >> By the way, Section 7 proposes two syntaxes for let binders in patterns, >> and I *strongly* prefer the second syntax, which reads something like `f >> (let b = Bool) (True :: Bool) = …`. >> >> Anyway, these are new, I feel that they are a bit out of place in a >> proposal that is about tidying up the existing designs. That being said, >> they are here, and they seem like fairly uncontroversial to me, (except, >> probably the syntax `(let b = _)` to bind a variable to a type to be filled >> by the compiler). I'm fine with accepting these, though they may require a >> bit more scrutiny than the rest. >> >> Best, >> Arnaud >> >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at chrisdornan.com Tue Jul 5 14:00:28 2022 From: chris at chrisdornan.com (Chris Dornan) Date: Tue, 5 Jul 2022 15:00:28 +0100 Subject: [ghc-steering-committee] Mind the gap In-Reply-To: <782F2059-9DD6-4D10-8D02-D08FF0C8E314@chrisdornan.com> References: <782F2059-9DD6-4D10-8D02-D08FF0C8E314@chrisdornan.com> Message-ID: <05B4C4D1-4BF1-424D-A8E7-7F6FA2006939@chrisdornan.com> I should provide some context to this. It is based on a problem that developed in a codebase I was working on — the only one that I am currently developing on GHC 9.2. It worked fine on 8.10 and 9.2 — for production builds — but broke down with bizarre type errors in its 9.2 development configuration. Eventually I wanted to consolidate around GHC 9.2 and spent some time isolating the problem, and realised that I wasn’t tying down the base language configuration in my development environment. I ran out of time before I could isolate the precise extension that was causing the error so I thought I would see if anybody could spot the problem on inspection. Needless to say it is a huge relief to have identify the underlying problem and am now attaching Haskell2010 to all of my source files in all of my code bases and will be using it in all non-trivial code snippets in blog posts etc. It has become my top language extension with some quite warm and pleasant associations! In many ways this is probably a positive development — we really should be being more explicit about the flavour of Haskell that we are using. Chris > On 2022-07-02, at 05:49, Chris Dornan wrote: > > Quick quiz: the below Haskell2010 ‘Phantoms' module (also in this Gist: https://gist.github.com/cdornan/f75cd8024434d998c87610cbb7fb6ab3) 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: > > Phantoms.hs:22:10: error: > • Could not deduce (Typeable k) > arising from the superclasses of an instance declaration > from the context: (C a, Typeable a) > bound by the instance declaration > at Phantoms.hs:22:10-36 > • In the instance declaration for ‘S (D a)’ > | > 22 | instance (C a,Typeable a) => S (D a) where smethod = undefined > | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Phantoms.hs:22:10: error: > • Could not deduce (Typeable k) > arising from the superclasses of an instance declaration > from the context: (C a, Typeable a) > bound by the instance declaration > at Phantoms.hs:22:10-36 > • In the instance declaration for ‘S (D a)’ > | > 22 | instance (C a,Typeable a) => S (D a) where smethod = undefined > > The question is which language extension(s) are giving rise to these errors? > > The ‘Phantoms' module is this: > > {-# LANGUAGE DerivingVia #-} > > module Phantoms where > > import Data.Typeable > > > class C a where > cmethod :: Proxy a -> () > > class (Show a, Typeable a) => S a where > smethod :: a -> Int > > > newtype UsingD a = UsingD { getUsingD :: a } > > > newtype D a = D { getD :: Int } > deriving (Show) via UsingD (D a) > > > instance (C a,Typeable a) => S (D a) where smethod = undefined > > instance (C a,Typeable a) => Show (UsingD a) where showsPrec = undefined > > > instance (C a) => C (D a) where cmethod _ = undefined > From lists at richarde.dev Tue Jul 5 14:00:33 2022 From: lists at richarde.dev (Richard Eisenberg) Date: Tue, 5 Jul 2022 14:00:33 +0000 Subject: [ghc-steering-committee] Mind the gap In-Reply-To: <782F2059-9DD6-4D10-8D02-D08FF0C8E314@chrisdornan.com> References: <782F2059-9DD6-4D10-8D02-D08FF0C8E314@chrisdornan.com> Message-ID: <010f0181cea9a561-58536013-fc08-4440-bb71-7338a5177c07-000000@us-east-2.amazonses.com> 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). Richard > On Jul 2, 2022, at 12:49 AM, Chris Dornan wrote: > > Quick quiz: the below Haskell2010 ‘Phantoms' module (also in this Gist: https://gist.github.com/cdornan/f75cd8024434d998c87610cbb7fb6ab3) 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: > > Phantoms.hs:22:10: error: > • Could not deduce (Typeable k) > arising from the superclasses of an instance declaration > from the context: (C a, Typeable a) > bound by the instance declaration > at Phantoms.hs:22:10-36 > • In the instance declaration for ‘S (D a)’ > | > 22 | instance (C a,Typeable a) => S (D a) where smethod = undefined > | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Phantoms.hs:22:10: error: > • Could not deduce (Typeable k) > arising from the superclasses of an instance declaration > from the context: (C a, Typeable a) > bound by the instance declaration > at Phantoms.hs:22:10-36 > • In the instance declaration for ‘S (D a)’ > | > 22 | instance (C a,Typeable a) => S (D a) where smethod = undefined > > The question is which language extension(s) are giving rise to these errors? > > The ‘Phantoms' module is this: > > {-# LANGUAGE DerivingVia #-} > > module Phantoms where > > import Data.Typeable > > > class C a where > cmethod :: Proxy a -> () > > class (Show a, Typeable a) => S a where > smethod :: a -> Int > > > newtype UsingD a = UsingD { getUsingD :: a } > > > newtype D a = D { getD :: Int } > deriving (Show) via UsingD (D a) > > > instance (C a,Typeable a) => S (D a) where smethod = undefined > > instance (C a,Typeable a) => Show (UsingD a) where showsPrec = undefined > > > instance (C a) => C (D a) where cmethod _ = undefined > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From lists at richarde.dev Tue Jul 5 14:59:37 2022 From: lists at richarde.dev (Richard Eisenberg) Date: Tue, 5 Jul 2022 14:59:37 +0000 Subject: [ghc-steering-committee] Modern Scoped Type Variables #448: recommendation (mostly) accept In-Reply-To: References: Message-ID: <010f0181cedfba97-3db8da90-f186-4ca9-a4c0-456245460bcb-000000@us-east-2.amazonses.com> > On Jul 5, 2022, at 2:58 AM, Spiwack, Arnaud wrote: > > Richard, do you agree? Yes, if the committee wishes to accept the proposal without the "let" bits, I'll remove them and move them to a separate proposal. But I would be dismayed if I do this work and then have the committee not accept or ask for yet another restructuring of this. Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at richarde.dev Tue Jul 5 15:02:58 2022 From: lists at richarde.dev (Richard Eisenberg) Date: Tue, 5 Jul 2022 15:02:58 +0000 Subject: [ghc-steering-committee] Mind the gap In-Reply-To: References: <782F2059-9DD6-4D10-8D02-D08FF0C8E314@chrisdornan.com> <010f0181cea9a561-58536013-fc08-4440-bb71-7338a5177c07-000000@us-east-2.amazonses.com> Message-ID: <010f0181cee2ca1c-8bbeac5e-b974-44c1-99be-38f224c757d9-000000@us-east-2.amazonses.com> 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... It would be interesting to learn more about what's going wrong. Richard > On Jul 5, 2022, at 10:26 AM, Chris Dornan wrote: > > yup, i should have started there—all my recent troubles have come from PolyKinds! > > On Tue, 5 Jul 2022 at 15:00, Richard Eisenberg > wrote: > 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). > > Richard > > > On Jul 2, 2022, at 12:49 AM, Chris Dornan > wrote: > > > > Quick quiz: the below Haskell2010 ‘Phantoms' module (also in this Gist: https://gist.github.com/cdornan/f75cd8024434d998c87610cbb7fb6ab3 ) 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: > > > > Phantoms.hs:22:10: error: > > • Could not deduce (Typeable k) > > arising from the superclasses of an instance declaration > > from the context: (C a, Typeable a) > > bound by the instance declaration > > at Phantoms.hs:22:10-36 > > • In the instance declaration for ‘S (D a)’ > > | > > 22 | instance (C a,Typeable a) => S (D a) where smethod = undefined > > | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > Phantoms.hs:22:10: error: > > • Could not deduce (Typeable k) > > arising from the superclasses of an instance declaration > > from the context: (C a, Typeable a) > > bound by the instance declaration > > at Phantoms.hs:22:10-36 > > • In the instance declaration for ‘S (D a)’ > > | > > 22 | instance (C a,Typeable a) => S (D a) where smethod = undefined > > > > The question is which language extension(s) are giving rise to these errors? > > > > The ‘Phantoms' module is this: > > > > {-# LANGUAGE DerivingVia #-} > > > > module Phantoms where > > > > import Data.Typeable > > > > > > class C a where > > cmethod :: Proxy a -> () > > > > class (Show a, Typeable a) => S a where > > smethod :: a -> Int > > > > > > newtype UsingD a = UsingD { getUsingD :: a } > > > > > > newtype D a = D { getD :: Int } > > deriving (Show) via UsingD (D a) > > > > > > instance (C a,Typeable a) => S (D a) where smethod = undefined > > > > instance (C a,Typeable a) => Show (UsingD a) where showsPrec = undefined > > > > > > instance (C a) => C (D a) where cmethod _ = undefined > > > > _______________________________________________ > > ghc-steering-committee mailing list > > ghc-steering-committee at haskell.org > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at chrisdornan.com Wed Jul 6 03:45:56 2022 From: chris at chrisdornan.com (Chris Dornan) Date: Wed, 6 Jul 2022 04:45:56 +0100 Subject: [ghc-steering-committee] Mind the gap In-Reply-To: <010f0181cee2ca1c-8bbeac5e-b974-44c1-99be-38f224c757d9-000000@us-east-2.amazonses.com> References: <782F2059-9DD6-4D10-8D02-D08FF0C8E314@chrisdornan.com> <010f0181cea9a561-58536013-fc08-4440-bb71-7338a5177c07-000000@us-east-2.amazonses.com> <010f0181cee2ca1c-8bbeac5e-b974-44c1-99be-38f224c757d9-000000@us-east-2.amazonses.com> Message-ID: 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. 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. At a minimum I would create ghc2022 = ghc2021 \ {PolyKinds} and make that the default for ghc-9.4. What do y’all think? > On 5 Jul 2022, at 16:02, Richard Eisenberg wrote: > > 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... > > It would be interesting to learn more about what's going wrong. > > Richard > >> On Jul 5, 2022, at 10:26 AM, Chris Dornan > wrote: >> >> yup, i should have started there—all my recent troubles have come from PolyKinds! >> >> On Tue, 5 Jul 2022 at 15:00, Richard Eisenberg > wrote: >> 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). >> >> Richard >> >> > On Jul 2, 2022, at 12:49 AM, Chris Dornan > wrote: >> > >> > Quick quiz: the below Haskell2010 ‘Phantoms' module (also in this Gist: https://gist.github.com/cdornan/f75cd8024434d998c87610cbb7fb6ab3 ) 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: >> > >> > Phantoms.hs:22:10: error: >> > • Could not deduce (Typeable k) >> > arising from the superclasses of an instance declaration >> > from the context: (C a, Typeable a) >> > bound by the instance declaration >> > at Phantoms.hs:22:10-36 >> > • In the instance declaration for ‘S (D a)’ >> > | >> > 22 | instance (C a,Typeable a) => S (D a) where smethod = undefined >> > | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> > >> > Phantoms.hs:22:10: error: >> > • Could not deduce (Typeable k) >> > arising from the superclasses of an instance declaration >> > from the context: (C a, Typeable a) >> > bound by the instance declaration >> > at Phantoms.hs:22:10-36 >> > • In the instance declaration for ‘S (D a)’ >> > | >> > 22 | instance (C a,Typeable a) => S (D a) where smethod = undefined >> > >> > The question is which language extension(s) are giving rise to these errors? >> > >> > The ‘Phantoms' module is this: >> > >> > {-# LANGUAGE DerivingVia #-} >> > >> > module Phantoms where >> > >> > import Data.Typeable >> > >> > >> > class C a where >> > cmethod :: Proxy a -> () >> > >> > class (Show a, Typeable a) => S a where >> > smethod :: a -> Int >> > >> > >> > newtype UsingD a = UsingD { getUsingD :: a } >> > >> > >> > newtype D a = D { getD :: Int } >> > deriving (Show) via UsingD (D a) >> > >> > >> > instance (C a,Typeable a) => S (D a) where smethod = undefined >> > >> > instance (C a,Typeable a) => Show (UsingD a) where showsPrec = undefined >> > >> > >> > instance (C a) => C (D a) where cmethod _ = undefined >> > >> > _______________________________________________ >> > ghc-steering-committee mailing list >> > ghc-steering-committee at haskell.org >> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cgibbard at gmail.com Wed Jul 6 03:51:07 2022 From: cgibbard at gmail.com (Cale Gibbard) Date: Tue, 5 Jul 2022 23:51:07 -0400 Subject: [ghc-steering-committee] Mind the gap In-Reply-To: References: <782F2059-9DD6-4D10-8D02-D08FF0C8E314@chrisdornan.com> <010f0181cea9a561-58536013-fc08-4440-bb71-7338a5177c07-000000@us-east-2.amazonses.com> <010f0181cee2ca1c-8bbeac5e-b974-44c1-99be-38f224c757d9-000000@us-east-2.amazonses.com> Message-ID: 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. On Tue, 5 Jul 2022 at 23:46, Chris Dornan wrote: > 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. > > 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. > > At a minimum I would create ghc2022 = ghc2021 \ {PolyKinds} and make that > the default for ghc-9.4. > > What do y’all think? > > > > On 5 Jul 2022, at 16:02, Richard Eisenberg wrote: > > 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... > > It would be interesting to learn more about what's going wrong. > > Richard > > On Jul 5, 2022, at 10:26 AM, Chris Dornan wrote: > > yup, i should have started there—all my recent troubles have come from > PolyKinds! > > On Tue, 5 Jul 2022 at 15:00, Richard Eisenberg wrote: > >> 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). >> >> Richard >> >> > On Jul 2, 2022, at 12:49 AM, Chris Dornan >> wrote: >> > >> > Quick quiz: the below Haskell2010 ‘Phantoms' module (also in this Gist: >> https://gist.github.com/cdornan/f75cd8024434d998c87610cbb7fb6ab3) >> 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: >> > >> > Phantoms.hs:22:10: error: >> > • Could not deduce (Typeable k) >> > arising from the superclasses of an instance declaration >> > from the context: (C a, Typeable a) >> > bound by the instance declaration >> > at Phantoms.hs:22:10-36 >> > • In the instance declaration for ‘S (D a)’ >> > | >> > 22 | instance (C a,Typeable a) => S (D a) where smethod = undefined >> > | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> > >> > Phantoms.hs:22:10: error: >> > • Could not deduce (Typeable k) >> > arising from the superclasses of an instance declaration >> > from the context: (C a, Typeable a) >> > bound by the instance declaration >> > at Phantoms.hs:22:10-36 >> > • In the instance declaration for ‘S (D a)’ >> > | >> > 22 | instance (C a,Typeable a) => S (D a) where smethod = undefined >> > >> > The question is which language extension(s) are giving rise to these >> errors? >> > >> > The ‘Phantoms' module is this: >> > >> > {-# LANGUAGE DerivingVia #-} >> > >> > module Phantoms where >> > >> > import Data.Typeable >> > >> > >> > class C a where >> > cmethod :: Proxy a -> () >> > >> > class (Show a, Typeable a) => S a where >> > smethod :: a -> Int >> > >> > >> > newtype UsingD a = UsingD { getUsingD :: a } >> > >> > >> > newtype D a = D { getD :: Int } >> > deriving (Show) via UsingD (D a) >> > >> > >> > instance (C a,Typeable a) => S (D a) where smethod = undefined >> > >> > instance (C a,Typeable a) => Show (UsingD a) where showsPrec = undefined >> > >> > >> > instance (C a) => C (D a) where cmethod _ = undefined >> > >> > _______________________________________________ >> > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at chrisdornan.com Wed Jul 6 03:58:57 2022 From: chris at chrisdornan.com (Chris Dornan) Date: Wed, 6 Jul 2022 04:58:57 +0100 Subject: [ghc-steering-committee] Mind the gap In-Reply-To: References: <782F2059-9DD6-4D10-8D02-D08FF0C8E314@chrisdornan.com> <010f0181cea9a561-58536013-fc08-4440-bb71-7338a5177c07-000000@us-east-2.amazonses.com> <010f0181cee2ca1c-8bbeac5e-b974-44c1-99be-38f224c757d9-000000@us-east-2.amazonses.com> Message-ID: <773ED5D2-1136-4FB1-8A3C-99D275C75B9F@chrisdornan.com> That speaks to why PolyKinds is needed in the long run. I don’t doubt that! (Especially after this report.) 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. Chris > On 6 Jul 2022, at 04:51, Cale Gibbard wrote: > > 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. > > On Tue, 5 Jul 2022 at 23:46, Chris Dornan > wrote: > 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. > > 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. > > At a minimum I would create ghc2022 = ghc2021 \ {PolyKinds} and make that the default for ghc-9.4. > > What do y’all think? > > > >> On 5 Jul 2022, at 16:02, Richard Eisenberg > wrote: >> >> 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... >> >> It would be interesting to learn more about what's going wrong. >> >> Richard >> >>> On Jul 5, 2022, at 10:26 AM, Chris Dornan > wrote: >>> >>> yup, i should have started there—all my recent troubles have come from PolyKinds! >>> >>> On Tue, 5 Jul 2022 at 15:00, Richard Eisenberg > wrote: >>> 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). >>> >>> Richard >>> >>> > On Jul 2, 2022, at 12:49 AM, Chris Dornan > wrote: >>> > >>> > Quick quiz: the below Haskell2010 ‘Phantoms' module (also in this Gist: https://gist.github.com/cdornan/f75cd8024434d998c87610cbb7fb6ab3 ) 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: >>> > >>> > Phantoms.hs:22:10: error: >>> > • Could not deduce (Typeable k) >>> > arising from the superclasses of an instance declaration >>> > from the context: (C a, Typeable a) >>> > bound by the instance declaration >>> > at Phantoms.hs:22:10-36 >>> > • In the instance declaration for ‘S (D a)’ >>> > | >>> > 22 | instance (C a,Typeable a) => S (D a) where smethod = undefined >>> > | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> > >>> > Phantoms.hs:22:10: error: >>> > • Could not deduce (Typeable k) >>> > arising from the superclasses of an instance declaration >>> > from the context: (C a, Typeable a) >>> > bound by the instance declaration >>> > at Phantoms.hs:22:10-36 >>> > • In the instance declaration for ‘S (D a)’ >>> > | >>> > 22 | instance (C a,Typeable a) => S (D a) where smethod = undefined >>> > >>> > The question is which language extension(s) are giving rise to these errors? >>> > >>> > The ‘Phantoms' module is this: >>> > >>> > {-# LANGUAGE DerivingVia #-} >>> > >>> > module Phantoms where >>> > >>> > import Data.Typeable >>> > >>> > >>> > class C a where >>> > cmethod :: Proxy a -> () >>> > >>> > class (Show a, Typeable a) => S a where >>> > smethod :: a -> Int >>> > >>> > >>> > newtype UsingD a = UsingD { getUsingD :: a } >>> > >>> > >>> > newtype D a = D { getD :: Int } >>> > deriving (Show) via UsingD (D a) >>> > >>> > >>> > instance (C a,Typeable a) => S (D a) where smethod = undefined >>> > >>> > instance (C a,Typeable a) => Show (UsingD a) where showsPrec = undefined >>> > >>> > >>> > instance (C a) => C (D a) where cmethod _ = undefined >>> > >>> > _______________________________________________ >>> > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From cgibbard at gmail.com Wed Jul 6 04:10:00 2022 From: cgibbard at gmail.com (Cale Gibbard) Date: Wed, 6 Jul 2022 00:10:00 -0400 Subject: [ghc-steering-committee] Mind the gap In-Reply-To: <773ED5D2-1136-4FB1-8A3C-99D275C75B9F@chrisdornan.com> References: <782F2059-9DD6-4D10-8D02-D08FF0C8E314@chrisdornan.com> <010f0181cea9a561-58536013-fc08-4440-bb71-7338a5177c07-000000@us-east-2.amazonses.com> <010f0181cee2ca1c-8bbeac5e-b974-44c1-99be-38f224c757d9-000000@us-east-2.amazonses.com> <773ED5D2-1136-4FB1-8A3C-99D275C75B9F@chrisdornan.com> Message-ID: 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. On Tue, 5 Jul 2022 at 23:58, Chris Dornan wrote: > That speaks to why PolyKinds is needed in the long run. I don’t doubt > that! (Especially after this report.) > > 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. > > Chris > > > > On 6 Jul 2022, at 04:51, Cale Gibbard wrote: > > 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. > > On Tue, 5 Jul 2022 at 23:46, Chris Dornan wrote: > >> 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. >> >> 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. >> >> At a minimum I would create ghc2022 = ghc2021 \ {PolyKinds} and make >> that the default for ghc-9.4. >> >> What do y’all think? >> >> >> >> On 5 Jul 2022, at 16:02, Richard Eisenberg wrote: >> >> 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... >> >> It would be interesting to learn more about what's going wrong. >> >> Richard >> >> On Jul 5, 2022, at 10:26 AM, Chris Dornan wrote: >> >> yup, i should have started there—all my recent troubles have come from >> PolyKinds! >> >> On Tue, 5 Jul 2022 at 15:00, Richard Eisenberg >> wrote: >> >>> 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). >>> >>> Richard >>> >>> > On Jul 2, 2022, at 12:49 AM, Chris Dornan >>> wrote: >>> > >>> > Quick quiz: the below Haskell2010 ‘Phantoms' module (also in this >>> Gist: https://gist.github.com/cdornan/f75cd8024434d998c87610cbb7fb6ab3) >>> 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: >>> > >>> > Phantoms.hs:22:10: error: >>> > • Could not deduce (Typeable k) >>> > arising from the superclasses of an instance declaration >>> > from the context: (C a, Typeable a) >>> > bound by the instance declaration >>> > at Phantoms.hs:22:10-36 >>> > • In the instance declaration for ‘S (D a)’ >>> > | >>> > 22 | instance (C a,Typeable a) => S (D a) where smethod = undefined >>> > | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> > >>> > Phantoms.hs:22:10: error: >>> > • Could not deduce (Typeable k) >>> > arising from the superclasses of an instance declaration >>> > from the context: (C a, Typeable a) >>> > bound by the instance declaration >>> > at Phantoms.hs:22:10-36 >>> > • In the instance declaration for ‘S (D a)’ >>> > | >>> > 22 | instance (C a,Typeable a) => S (D a) where smethod = undefined >>> > >>> > The question is which language extension(s) are giving rise to these >>> errors? >>> > >>> > The ‘Phantoms' module is this: >>> > >>> > {-# LANGUAGE DerivingVia #-} >>> > >>> > module Phantoms where >>> > >>> > import Data.Typeable >>> > >>> > >>> > class C a where >>> > cmethod :: Proxy a -> () >>> > >>> > class (Show a, Typeable a) => S a where >>> > smethod :: a -> Int >>> > >>> > >>> > newtype UsingD a = UsingD { getUsingD :: a } >>> > >>> > >>> > newtype D a = D { getD :: Int } >>> > deriving (Show) via UsingD (D a) >>> > >>> > >>> > instance (C a,Typeable a) => S (D a) where smethod = undefined >>> > >>> > instance (C a,Typeable a) => Show (UsingD a) where showsPrec = >>> undefined >>> > >>> > >>> > instance (C a) => C (D a) where cmethod _ = undefined >>> > >>> > _______________________________________________ >>> > 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 >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cgibbard at gmail.com Wed Jul 6 04:38:53 2022 From: cgibbard at gmail.com (Cale Gibbard) Date: Wed, 6 Jul 2022 00:38:53 -0400 Subject: [ghc-steering-committee] Mind the gap In-Reply-To: References: <782F2059-9DD6-4D10-8D02-D08FF0C8E314@chrisdornan.com> <010f0181cea9a561-58536013-fc08-4440-bb71-7338a5177c07-000000@us-east-2.amazonses.com> <010f0181cee2ca1c-8bbeac5e-b974-44c1-99be-38f224c757d9-000000@us-east-2.amazonses.com> <773ED5D2-1136-4FB1-8A3C-99D275C75B9F@chrisdornan.com> Message-ID: Also, the Foo not matching Foo case isn't even the worst -- at least there you can tell something is up, because it's absurd on the face of it. The worse examples are cases where there's a type error caused by lack of PolyKinds that if you thought about it long enough, would seem absurd, but the compiler isn't *obviously* saying something wrong -- then you potentially waste a whole bunch of time trying to reason it out before discovering that just turning PolyKinds on fixes the issue. Probably the real answer is just to fix GHC's error message printing, but in the meantime... On Wed, 6 Jul 2022 at 00:10, Cale Gibbard wrote: > 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. > > On Tue, 5 Jul 2022 at 23:58, Chris Dornan wrote: > >> That speaks to why PolyKinds is needed in the long run. I don’t doubt >> that! (Especially after this report.) >> >> 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. >> >> Chris >> >> >> >> On 6 Jul 2022, at 04:51, Cale Gibbard wrote: >> >> 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. >> >> On Tue, 5 Jul 2022 at 23:46, Chris Dornan wrote: >> >>> 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. >>> >>> 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. >>> >>> At a minimum I would create ghc2022 = ghc2021 \ {PolyKinds} and make >>> that the default for ghc-9.4. >>> >>> What do y’all think? >>> >>> >>> >>> On 5 Jul 2022, at 16:02, Richard Eisenberg wrote: >>> >>> 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... >>> >>> It would be interesting to learn more about what's going wrong. >>> >>> Richard >>> >>> On Jul 5, 2022, at 10:26 AM, Chris Dornan wrote: >>> >>> yup, i should have started there—all my recent troubles have come from >>> PolyKinds! >>> >>> On Tue, 5 Jul 2022 at 15:00, Richard Eisenberg >>> wrote: >>> >>>> 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). >>>> >>>> Richard >>>> >>>> > On Jul 2, 2022, at 12:49 AM, Chris Dornan >>>> wrote: >>>> > >>>> > Quick quiz: the below Haskell2010 ‘Phantoms' module (also in this >>>> Gist: https://gist.github.com/cdornan/f75cd8024434d998c87610cbb7fb6ab3) >>>> 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: >>>> > >>>> > Phantoms.hs:22:10: error: >>>> > • Could not deduce (Typeable k) >>>> > arising from the superclasses of an instance declaration >>>> > from the context: (C a, Typeable a) >>>> > bound by the instance declaration >>>> > at Phantoms.hs:22:10-36 >>>> > • In the instance declaration for ‘S (D a)’ >>>> > | >>>> > 22 | instance (C a,Typeable a) => S (D a) where smethod = undefined >>>> > | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>> > >>>> > Phantoms.hs:22:10: error: >>>> > • Could not deduce (Typeable k) >>>> > arising from the superclasses of an instance declaration >>>> > from the context: (C a, Typeable a) >>>> > bound by the instance declaration >>>> > at Phantoms.hs:22:10-36 >>>> > • In the instance declaration for ‘S (D a)’ >>>> > | >>>> > 22 | instance (C a,Typeable a) => S (D a) where smethod = undefined >>>> > >>>> > The question is which language extension(s) are giving rise to these >>>> errors? >>>> > >>>> > The ‘Phantoms' module is this: >>>> > >>>> > {-# LANGUAGE DerivingVia #-} >>>> > >>>> > module Phantoms where >>>> > >>>> > import Data.Typeable >>>> > >>>> > >>>> > class C a where >>>> > cmethod :: Proxy a -> () >>>> > >>>> > class (Show a, Typeable a) => S a where >>>> > smethod :: a -> Int >>>> > >>>> > >>>> > newtype UsingD a = UsingD { getUsingD :: a } >>>> > >>>> > >>>> > newtype D a = D { getD :: Int } >>>> > deriving (Show) via UsingD (D a) >>>> > >>>> > >>>> > instance (C a,Typeable a) => S (D a) where smethod = undefined >>>> > >>>> > instance (C a,Typeable a) => Show (UsingD a) where showsPrec = >>>> undefined >>>> > >>>> > >>>> > instance (C a) => C (D a) where cmethod _ = undefined >>>> > >>>> > _______________________________________________ >>>> > 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 >>> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.spiwack at tweag.io Wed Jul 6 07:32:04 2022 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Wed, 6 Jul 2022 09:32:04 +0200 Subject: [ghc-steering-committee] Modern Scoped Type Variables #448: recommendation (mostly) accept In-Reply-To: <010f0181cedfba97-3db8da90-f186-4ca9-a4c0-456245460bcb-000000@us-east-2.amazonses.com> References: <010f0181cedfba97-3db8da90-f186-4ca9-a4c0-456245460bcb-000000@us-east-2.amazonses.com> Message-ID: Very well, if nobody objects by the end of the week, I'll make this decision final. On Tue, Jul 5, 2022 at 4:59 PM Richard Eisenberg wrote: > > > On Jul 5, 2022, at 2:58 AM, Spiwack, Arnaud > wrote: > > Richard, do you agree? > > > Yes, if the committee wishes to accept the proposal without the "let" > bits, I'll remove them and move them to a separate proposal. But I would be > dismayed if I do this work and then have the committee not accept or ask > for yet another restructuring of this. > > Richard > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.peytonjones at gmail.com Wed Jul 6 08:35:28 2022 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Wed, 6 Jul 2022 09:35:28 +0100 Subject: [ghc-steering-committee] Mind the gap In-Reply-To: <010f0181cee2ca1c-8bbeac5e-b974-44c1-99be-38f224c757d9-000000@us-east-2.amazonses.com> References: <782F2059-9DD6-4D10-8D02-D08FF0C8E314@chrisdornan.com> <010f0181cea9a561-58536013-fc08-4440-bb71-7338a5177c07-000000@us-east-2.amazonses.com> <010f0181cee2ca1c-8bbeac5e-b974-44c1-99be-38f224c757d9-000000@us-east-2.amazonses.com> Message-ID: Like Richard, I'd be sad to think that PolyKinds is causing problems, and would like to understand better. For example, at the term level we wioudl not dream of making monomorphism the default! So why would we do that at the type level? Maybe it is a shortcoming of inference or error messages. However the error is a bit perplexing. class (Typeable a) => S a newtype D a = D { getD :: Int } instance (Typeable a) => S (D a) We get the error Chris shows. But it looks as if we have done all that is needful. We need (Typeable (D a)) and we have provided (Typeable a). What gives? Well, what we really need is (Typeable (D @k a)), and for that we need (Typeable k) too. But that's very far from clear. I sort of wonder: if we have (Typeable t) should that not give us (Typeable k) where (t :: k)? That would require us to have a function typeRepKind :: TypeRep (a::k) -> TypeRep k, and I don't know how hard that is to get. Simon On Tue, 5 Jul 2022 at 16:03, Richard Eisenberg wrote: > 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... > > It would be interesting to learn more about what's going wrong. > > Richard > > On Jul 5, 2022, at 10:26 AM, Chris Dornan wrote: > > yup, i should have started there—all my recent troubles have come from > PolyKinds! > > On Tue, 5 Jul 2022 at 15:00, Richard Eisenberg wrote: > >> 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). >> >> Richard >> >> > On Jul 2, 2022, at 12:49 AM, Chris Dornan >> wrote: >> > >> > Quick quiz: the below Haskell2010 ‘Phantoms' module (also in this Gist: >> https://gist.github.com/cdornan/f75cd8024434d998c87610cbb7fb6ab3) >> 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: >> > >> > Phantoms.hs:22:10: error: >> > • Could not deduce (Typeable k) >> > arising from the superclasses of an instance declaration >> > from the context: (C a, Typeable a) >> > bound by the instance declaration >> > at Phantoms.hs:22:10-36 >> > • In the instance declaration for ‘S (D a)’ >> > | >> > 22 | instance (C a,Typeable a) => S (D a) where smethod = undefined >> > | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> > >> > Phantoms.hs:22:10: error: >> > • Could not deduce (Typeable k) >> > arising from the superclasses of an instance declaration >> > from the context: (C a, Typeable a) >> > bound by the instance declaration >> > at Phantoms.hs:22:10-36 >> > • In the instance declaration for ‘S (D a)’ >> > | >> > 22 | instance (C a,Typeable a) => S (D a) where smethod = undefined >> > >> > The question is which language extension(s) are giving rise to these >> errors? >> > >> > The ‘Phantoms' module is this: >> > >> > {-# LANGUAGE DerivingVia #-} >> > >> > module Phantoms where >> > >> > import Data.Typeable >> > >> > >> > class C a where >> > cmethod :: Proxy a -> () >> > >> > class (Show a, Typeable a) => S a where >> > smethod :: a -> Int >> > >> > >> > newtype UsingD a = UsingD { getUsingD :: a } >> > >> > >> > newtype D a = D { getD :: Int } >> > deriving (Show) via UsingD (D a) >> > >> > >> > instance (C a,Typeable a) => S (D a) where smethod = undefined >> > >> > instance (C a,Typeable a) => Show (UsingD a) where showsPrec = undefined >> > >> > >> > instance (C a) => C (D a) where cmethod _ = undefined >> > >> > _______________________________________________ >> > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at chrisdornan.com Wed Jul 6 09:08:34 2022 From: chris at chrisdornan.com (Chris Dornan) Date: Wed, 6 Jul 2022 10:08:34 +0100 Subject: [ghc-steering-committee] Mind the gap In-Reply-To: References: <782F2059-9DD6-4D10-8D02-D08FF0C8E314@chrisdornan.com> <010f0181cea9a561-58536013-fc08-4440-bb71-7338a5177c07-000000@us-east-2.amazonses.com> <010f0181cee2ca1c-8bbeac5e-b974-44c1-99be-38f224c757d9-000000@us-east-2.amazonses.com> Message-ID: <4188A46B-8C22-4346-9A98-AE1B1D4B63B2@chrisdornan.com> I am going to strengthen my statement and keep restating it — PolyKinds is for sure our destination, the path to it is the question. I am just as perplexed as Simon on why it is breaking like this and it would be great to understand it better. Chris > On 6 Jul 2022, at 09:35, Simon Peyton Jones wrote: > > Like Richard, I'd be sad to think that PolyKinds is causing problems, and would like to understand better. For example, at the term level we wioudl not dream of making monomorphism the default! So why would we do that at the type level? Maybe it is a shortcoming of inference or error messages. > > However the error is a bit perplexing. > > class (Typeable a) => S a > > newtype D a = D { getD :: Int } > > instance (Typeable a) => S (D a) > > We get the error Chris shows. But it looks as if we have done all that is needful. We need (Typeable (D a)) and we have provided (Typeable a). What gives? Well, what we really need is (Typeable (D @k a)), and for that we need (Typeable k) too. But that's very far from clear. > > I sort of wonder: if we have (Typeable t) should that not give us (Typeable k) where (t :: k)? That would require us to have a function typeRepKind :: TypeRep (a::k) -> TypeRep k, and I don't know how hard that is to get. > > Simon > > On Tue, 5 Jul 2022 at 16:03, Richard Eisenberg > wrote: > 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... > > It would be interesting to learn more about what's going wrong. > > Richard > >> On Jul 5, 2022, at 10:26 AM, Chris Dornan > wrote: >> >> yup, i should have started there—all my recent troubles have come from PolyKinds! >> >> On Tue, 5 Jul 2022 at 15:00, Richard Eisenberg > wrote: >> 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). >> >> Richard >> >> > On Jul 2, 2022, at 12:49 AM, Chris Dornan > wrote: >> > >> > Quick quiz: the below Haskell2010 ‘Phantoms' module (also in this Gist: https://gist.github.com/cdornan/f75cd8024434d998c87610cbb7fb6ab3 ) 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: >> > >> > Phantoms.hs:22:10: error: >> > • Could not deduce (Typeable k) >> > arising from the superclasses of an instance declaration >> > from the context: (C a, Typeable a) >> > bound by the instance declaration >> > at Phantoms.hs:22:10-36 >> > • In the instance declaration for ‘S (D a)’ >> > | >> > 22 | instance (C a,Typeable a) => S (D a) where smethod = undefined >> > | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> > >> > Phantoms.hs:22:10: error: >> > • Could not deduce (Typeable k) >> > arising from the superclasses of an instance declaration >> > from the context: (C a, Typeable a) >> > bound by the instance declaration >> > at Phantoms.hs:22:10-36 >> > • In the instance declaration for ‘S (D a)’ >> > | >> > 22 | instance (C a,Typeable a) => S (D a) where smethod = undefined >> > >> > The question is which language extension(s) are giving rise to these errors? >> > >> > The ‘Phantoms' module is this: >> > >> > {-# LANGUAGE DerivingVia #-} >> > >> > module Phantoms where >> > >> > import Data.Typeable >> > >> > >> > class C a where >> > cmethod :: Proxy a -> () >> > >> > class (Show a, Typeable a) => S a where >> > smethod :: a -> Int >> > >> > >> > newtype UsingD a = UsingD { getUsingD :: a } >> > >> > >> > newtype D a = D { getD :: Int } >> > deriving (Show) via UsingD (D a) >> > >> > >> > instance (C a,Typeable a) => S (D a) where smethod = undefined >> > >> > instance (C a,Typeable a) => Show (UsingD a) where showsPrec = undefined >> > >> > >> > instance (C a) => C (D a) where cmethod _ = undefined >> > >> > _______________________________________________ >> > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at chrisdornan.com Wed Jul 6 09:14:40 2022 From: chris at chrisdornan.com (Chris Dornan) Date: Wed, 6 Jul 2022 10:14:40 +0100 Subject: [ghc-steering-committee] Mind the gap In-Reply-To: References: <782F2059-9DD6-4D10-8D02-D08FF0C8E314@chrisdornan.com> <010f0181cea9a561-58536013-fc08-4440-bb71-7338a5177c07-000000@us-east-2.amazonses.com> <010f0181cee2ca1c-8bbeac5e-b974-44c1-99be-38f224c757d9-000000@us-east-2.amazonses.com> Message-ID: <41DC854B-0696-465C-8465-D29BFDB6BA67@chrisdornan.com> On Simon’s analogy, I think what we might be doing could be a little bit like enabling OverloadedStrings in the default language. For sure it is absolutely critical for modern Haskell but the preemptive injection of polymorphism can cause problems, especially when it is not all clear what is happening from the diagnostics. > On 6 Jul 2022, at 09:35, Simon Peyton Jones wrote: > > Like Richard, I'd be sad to think that PolyKinds is causing problems, and would like to understand better. For example, at the term level we wioudl not dream of making monomorphism the default! So why would we do that at the type level? Maybe it is a shortcoming of inference or error messages. > > However the error is a bit perplexing. > > class (Typeable a) => S a > > newtype D a = D { getD :: Int } > > instance (Typeable a) => S (D a) > > We get the error Chris shows. But it looks as if we have done all that is needful. We need (Typeable (D a)) and we have provided (Typeable a). What gives? Well, what we really need is (Typeable (D @k a)), and for that we need (Typeable k) too. But that's very far from clear. > > I sort of wonder: if we have (Typeable t) should that not give us (Typeable k) where (t :: k)? That would require us to have a function typeRepKind :: TypeRep (a::k) -> TypeRep k, and I don't know how hard that is to get. > > Simon > > On Tue, 5 Jul 2022 at 16:03, Richard Eisenberg > wrote: > 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... > > It would be interesting to learn more about what's going wrong. > > Richard > >> On Jul 5, 2022, at 10:26 AM, Chris Dornan > wrote: >> >> yup, i should have started there—all my recent troubles have come from PolyKinds! >> >> On Tue, 5 Jul 2022 at 15:00, Richard Eisenberg > wrote: >> 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). >> >> Richard >> >> > On Jul 2, 2022, at 12:49 AM, Chris Dornan > wrote: >> > >> > Quick quiz: the below Haskell2010 ‘Phantoms' module (also in this Gist: https://gist.github.com/cdornan/f75cd8024434d998c87610cbb7fb6ab3 ) 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: >> > >> > Phantoms.hs:22:10: error: >> > • Could not deduce (Typeable k) >> > arising from the superclasses of an instance declaration >> > from the context: (C a, Typeable a) >> > bound by the instance declaration >> > at Phantoms.hs:22:10-36 >> > • In the instance declaration for ‘S (D a)’ >> > | >> > 22 | instance (C a,Typeable a) => S (D a) where smethod = undefined >> > | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> > >> > Phantoms.hs:22:10: error: >> > • Could not deduce (Typeable k) >> > arising from the superclasses of an instance declaration >> > from the context: (C a, Typeable a) >> > bound by the instance declaration >> > at Phantoms.hs:22:10-36 >> > • In the instance declaration for ‘S (D a)’ >> > | >> > 22 | instance (C a,Typeable a) => S (D a) where smethod = undefined >> > >> > The question is which language extension(s) are giving rise to these errors? >> > >> > The ‘Phantoms' module is this: >> > >> > {-# LANGUAGE DerivingVia #-} >> > >> > module Phantoms where >> > >> > import Data.Typeable >> > >> > >> > class C a where >> > cmethod :: Proxy a -> () >> > >> > class (Show a, Typeable a) => S a where >> > smethod :: a -> Int >> > >> > >> > newtype UsingD a = UsingD { getUsingD :: a } >> > >> > >> > newtype D a = D { getD :: Int } >> > deriving (Show) via UsingD (D a) >> > >> > >> > instance (C a,Typeable a) => S (D a) where smethod = undefined >> > >> > instance (C a,Typeable a) => Show (UsingD a) where showsPrec = undefined >> > >> > >> > instance (C a) => C (D a) where cmethod _ = undefined >> > >> > _______________________________________________ >> > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at richarde.dev Wed Jul 6 11:51:16 2022 From: lists at richarde.dev (Richard Eisenberg) Date: Wed, 6 Jul 2022 11:51:16 +0000 Subject: [ghc-steering-committee] Mind the gap In-Reply-To: References: <782F2059-9DD6-4D10-8D02-D08FF0C8E314@chrisdornan.com> <010f0181cea9a561-58536013-fc08-4440-bb71-7338a5177c07-000000@us-east-2.amazonses.com> <010f0181cee2ca1c-8bbeac5e-b974-44c1-99be-38f224c757d9-000000@us-east-2.amazonses.com> Message-ID: <010f0181d359a5e5-cf7dac43-9350-4251-8839-3baa21c2dc0c-000000@us-east-2.amazonses.com> > On Jul 6, 2022, at 4:35 AM, Simon Peyton Jones wrote: > > I sort of wonder: if we have (Typeable t) should that not give us (Typeable k) where (t :: k)? That would require us to have a function typeRepKind :: TypeRep (a::k) -> TypeRep k, and I don't know how hard that is to get. We have that function. It's called typeRepKind. What we need for this example is a superclass constraint: class Typeable k => Typeable (a :: k) which would probably require UndecidableSuperClasses, but otherwise might just work. Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at chrisdornan.com Wed Jul 6 12:00:34 2022 From: chris at chrisdornan.com (Chris Dornan) Date: Wed, 6 Jul 2022 13:00:34 +0100 Subject: [ghc-steering-committee] Mind the gap In-Reply-To: <010f0181d359a5e5-cf7dac43-9350-4251-8839-3baa21c2dc0c-000000@us-east-2.amazonses.com> References: <782F2059-9DD6-4D10-8D02-D08FF0C8E314@chrisdornan.com> <010f0181cea9a561-58536013-fc08-4440-bb71-7338a5177c07-000000@us-east-2.amazonses.com> <010f0181cee2ca1c-8bbeac5e-b974-44c1-99be-38f224c757d9-000000@us-east-2.amazonses.com> <010f0181d359a5e5-cf7dac43-9350-4251-8839-3baa21c2dc0c-000000@us-east-2.amazonses.com> Message-ID: <2BED5557-48DC-405D-B815-0857954339F6@chrisdornan.com> Richard are you satisfied that my example program is invalid under PolyKinds? > On 6 Jul 2022, at 12:51, Richard Eisenberg wrote: > > > >> On Jul 6, 2022, at 4:35 AM, Simon Peyton Jones > wrote: >> >> I sort of wonder: if we have (Typeable t) should that not give us (Typeable k) where (t :: k)? That would require us to have a function typeRepKind :: TypeRep (a::k) -> TypeRep k, and I don't know how hard that is to get. > > We have that function. It's called typeRepKind. What we need for this example is a superclass constraint: > > class Typeable k => Typeable (a :: k) > > which would probably require UndecidableSuperClasses, but otherwise might just work. > > Richard > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Wed Jul 6 12:10:28 2022 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 06 Jul 2022 14:10:28 +0200 Subject: [ghc-steering-committee] Please review #518: Type vs Constraint proposal, Shepherd: Eric Message-ID: <3923c3181ede270d8a37d0657550bac534af8676.camel@joachim-breitner.de> Dear Committee, The Type vs Constraint proposal has been submitted by Richard Eisenberg and Simon Peyton Jones https://github.com/ghc-proposals/ghc-proposals/pull/518 https://github.com/ghc-proposals/ghc-proposals/blob/spj/type-vs-constraint/proposals/0000-type-vs-constraint.rst I suggest that Eric shepherds this proposal. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Thanks, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From lists at richarde.dev Wed Jul 6 14:01:44 2022 From: lists at richarde.dev (Richard Eisenberg) Date: Wed, 6 Jul 2022 14:01:44 +0000 Subject: [ghc-steering-committee] Mind the gap In-Reply-To: <2BED5557-48DC-405D-B815-0857954339F6@chrisdornan.com> References: <782F2059-9DD6-4D10-8D02-D08FF0C8E314@chrisdornan.com> <010f0181cea9a561-58536013-fc08-4440-bb71-7338a5177c07-000000@us-east-2.amazonses.com> <010f0181cee2ca1c-8bbeac5e-b974-44c1-99be-38f224c757d9-000000@us-east-2.amazonses.com> <010f0181d359a5e5-cf7dac43-9350-4251-8839-3baa21c2dc0c-000000@us-east-2.amazonses.com> <2BED5557-48DC-405D-B815-0857954339F6@chrisdornan.com> Message-ID: <010f0181d3d11546-01878be9-8464-47b9-8d0e-4d902697db2c-000000@us-east-2.amazonses.com> > On Jul 6, 2022, at 8:00 AM, Chris Dornan wrote: > > Richard are you satisfied that my example program is invalid under PolyKinds? Yes. But I think as we've started to piece together, the real problem in this example is a missing superclass constraint on Typeable, not a fundamental shortcoming of PolyKinds. (I do acknowledge that extra polymorphism can introduce trouble, but given the fact that PolyKinds introduces parametric polymorphism -- unlike the ad hoc polymorphism of OverloadedStrings -- I think these cases should be rare.) It would be interesting to see whether fixing Typeable in this way fixes other problems Chris has run into. Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.peytonjones at gmail.com Wed Jul 6 14:11:22 2022 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Wed, 6 Jul 2022 15:11:22 +0100 Subject: [ghc-steering-committee] Mind the gap In-Reply-To: <010f0181d3d11546-01878be9-8464-47b9-8d0e-4d902697db2c-000000@us-east-2.amazonses.com> References: <782F2059-9DD6-4D10-8D02-D08FF0C8E314@chrisdornan.com> <010f0181cea9a561-58536013-fc08-4440-bb71-7338a5177c07-000000@us-east-2.amazonses.com> <010f0181cee2ca1c-8bbeac5e-b974-44c1-99be-38f224c757d9-000000@us-east-2.amazonses.com> <010f0181d359a5e5-cf7dac43-9350-4251-8839-3baa21c2dc0c-000000@us-east-2.amazonses.com> <2BED5557-48DC-405D-B815-0857954339F6@chrisdornan.com> <010f0181d3d11546-01878be9-8464-47b9-8d0e-4d902697db2c-000000@us-east-2.amazonses.com> Message-ID: See #21822 (https://gitlab.haskell.org/ghc/ghc/-/issues/21822) and #14190 /#16627 ! Simon On Wed, 6 Jul 2022 at 15:01, Richard Eisenberg wrote: > > > On Jul 6, 2022, at 8:00 AM, Chris Dornan wrote: > > Richard are you satisfied that my example program is invalid under > PolyKinds? > > > Yes. But I think as we've started to piece together, the real problem in > this example is a missing superclass constraint on Typeable, not a > fundamental shortcoming of PolyKinds. (I do acknowledge that extra > polymorphism can introduce trouble, but given the fact that PolyKinds > introduces parametric polymorphism -- unlike the ad hoc polymorphism of > OverloadedStrings -- I think these cases should be rare.) > > It would be interesting to see whether fixing Typeable in this way fixes > other problems Chris has run into. > > Richard > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.spiwack at tweag.io Mon Jul 11 07:24:46 2022 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Mon, 11 Jul 2022 09:24:46 +0200 Subject: [ghc-steering-committee] Modern Scoped Type Variables #448: recommendation (mostly) accept In-Reply-To: References: <010f0181cedfba97-3db8da90-f186-4ca9-a4c0-456245460bcb-000000@us-east-2.amazonses.com> Message-ID: I've now made the decision final. On Wed, Jul 6, 2022 at 9:32 AM Spiwack, Arnaud wrote: > Very well, if nobody objects by the end of the week, I'll make this > decision final. > > On Tue, Jul 5, 2022 at 4:59 PM Richard Eisenberg > wrote: > >> >> >> On Jul 5, 2022, at 2:58 AM, Spiwack, Arnaud >> wrote: >> >> Richard, do you agree? >> >> >> Yes, if the committee wishes to accept the proposal without the "let" >> bits, I'll remove them and move them to a separate proposal. But I would be >> dismayed if I do this work and then have the committee not accept or ask >> for yet another restructuring of this. >> >> Richard >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at seidel.io Wed Jul 13 00:50:34 2022 From: eric at seidel.io (Eric Seidel) Date: Tue, 12 Jul 2022 20:50:34 -0400 Subject: [ghc-steering-committee] Please review #518: Type vs Constraint proposal, Shepherd: Eric In-Reply-To: <3923c3181ede270d8a37d0657550bac534af8676.camel@joachim-breitner.de> References: <3923c3181ede270d8a37d0657550bac534af8676.camel@joachim-breitner.de> Message-ID: <50f03efe-cf2f-42e7-9d73-07da304cdd4b@www.fastmail.com> Hi all, Richard and Simon PJ have proposed tightening up the distinction between Type and Constraint in the type system. This proposal is primarily motivated by eliminating a long-standing class of compiler bugs, but it introduces a number of new (user-facing) types at the core of GHC's type system. And it does bring with it some additional capabilities like unboxed and unlifted implicit parameters, and a greater ability to abstract over arrows. I recommend acceptance of the proposal, but there is one question that I would like the broader committee to engage on. Simon and Richard have proposed introducing another arrow type as part of this proposal. type (==>) :: forall (r1 :: RuntimeRep) (r2 :: RuntimeRep). CONSTRAINT r1 -> CONSTRAINT r2 -> Constraint I am a bit wary of introducing this arrow as a stable API at this point. It does not seem strictly necessary to make this part of the public API to implement this proposal, but doing so would commit us to a particular point in the design space. I've started a thread to discuss this on GitHub, please take a look and chime in if you have thoughts. https://github.com/ghc-proposals/ghc-proposals/pull/518#discussion_r917416818 Thanks! Eric On Wed, Jul 6, 2022, at 08:10, Joachim Breitner wrote: > Dear Committee, > > The Type vs Constraint proposal > has been submitted by Richard Eisenberg and Simon Peyton Jones > > https://github.com/ghc-proposals/ghc-proposals/pull/518 > https://github.com/ghc-proposals/ghc-proposals/blob/spj/type-vs-constraint/proposals/0000-type-vs-constraint.rst > > I suggest that Eric shepherds this proposal. > > Please guide us to a conclusion as outlined in > https://github.com/ghc-proposals/ghc-proposals#committee-process > > Thanks, > 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 From arnaud.spiwack at tweag.io Wed Jul 13 14:52:37 2022 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Wed, 13 Jul 2022 16:52:37 +0200 Subject: [ghc-steering-committee] Please review #518: Type vs Constraint proposal, Shepherd: Eric In-Reply-To: <50f03efe-cf2f-42e7-9d73-07da304cdd4b@www.fastmail.com> References: <3923c3181ede270d8a37d0657550bac534af8676.camel@joachim-breitner.de> <50f03efe-cf2f-42e7-9d73-07da304cdd4b@www.fastmail.com> Message-ID: As I've voiced in the thread, I'm not particularly fond of this proposal's design. That being said, the issues it means to address are serious, and they are pressing. Simon and Richard think it's the best path forward for them, and therefore I vote acceptance. On Wed, Jul 13, 2022 at 2:51 AM Eric Seidel wrote: > Hi all, > > Richard and Simon PJ have proposed tightening up the distinction between > Type and Constraint in the type system. This proposal is primarily > motivated by eliminating a long-standing class of compiler bugs, but it > introduces a number of new (user-facing) types at the core of GHC's type > system. And it does bring with it some additional capabilities like unboxed > and unlifted implicit parameters, and a greater ability to abstract over > arrows. > > I recommend acceptance of the proposal, but there is one question that I > would like the broader committee to engage on. > > Simon and Richard have proposed introducing another arrow type as part of > this proposal. > > type (==>) :: forall (r1 :: RuntimeRep) (r2 :: RuntimeRep). > CONSTRAINT r1 -> CONSTRAINT r2 -> Constraint > > I am a bit wary of introducing this arrow as a stable API at this point. > It does not seem strictly necessary to make this part of the public API to > implement this proposal, but doing so would commit us to a particular point > in the design space. I've started a thread to discuss this on GitHub, > please take a look and chime in if you have thoughts. > > > https://github.com/ghc-proposals/ghc-proposals/pull/518#discussion_r917416818 > > Thanks! > Eric > > On Wed, Jul 6, 2022, at 08:10, Joachim Breitner wrote: > > Dear Committee, > > > > The Type vs Constraint proposal > > has been submitted by Richard Eisenberg and Simon Peyton Jones > > > > https://github.com/ghc-proposals/ghc-proposals/pull/518 > > > https://github.com/ghc-proposals/ghc-proposals/blob/spj/type-vs-constraint/proposals/0000-type-vs-constraint.rst > > > > I suggest that Eric shepherds this proposal. > > > > Please guide us to a conclusion as outlined in > > https://github.com/ghc-proposals/ghc-proposals#committee-process > > > > Thanks, > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Thu Jul 14 15:59:44 2022 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 14 Jul 2022 17:59:44 +0200 Subject: [ghc-steering-committee] Vacation Message-ID: <883b5d73bcca179efbc23c7de3713ae64e13ed60.camel@joachim-breitner.de> Hi all, I’ll be traveling for two weeks from this weekend on, without a laptop, and hopefully also with a low email checking frequency on the phone. Very likely I will no look into mailing list folders. I hope someone else can play secretary in the meantime for whatever can’t wait until August. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From mail at joachim-breitner.de Fri Jul 29 20:24:32 2022 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 29 Jul 2022 22:24:32 +0200 Subject: [ghc-steering-committee] How I pick shepherds Message-ID: <4af2d38b2efb8f7342fe6605de59388cbe4383cc.camel@joachim-breitner.de> Hi committee, I’m back, and I _think_ I have caught up on committee work. If you expected me to do something when back and I have not done it yet, I probably forgot and will appreciate a nudge. Richard writes > While I'm happy to take over some of his responsibilities, I don't  > have access to the proposal-assigning algorithm. (I can view the > current state of who has open proposals, but I don't have easy access > to e.g. the recent history to accomplish load-balancing.) and I have to disappoint you: there isn’t much of an algorithm there. It’s all manual and very subjective. Here is what I do to assign a proposal: I open these three links (all linked from the beginning of the README) to remind myself of who is actually on the committee, and who is already shepherding a proposal: https://github.com/ghc-proposals/ghc-proposals#who-is-the-committee https://github.com/ghc-proposals/ghc-proposals/pulls?q=is%3Aopen+is%3Apr+label%3A%22Pending+shepherd+recommendation%22 https://github.com/ghc-proposals/ghc-proposals/pulls?q=is%3Aopen+is%3Apr+label%3A%22Pending+committee+review%22 This way I see who is currently not shepherding. I recently added the profile pictures to the Who-is-the-committee section to make that part easier. Then I just pick someone, keeping in mind what I believe is the person’s interest and strength. If someone has already commented on a proposal, they are more likely to become shepherd. I avoid assigning to Chairs unless I have a good reason to. Intuitively, some members are more, well, efficient, others are particularly thorough; I try to keep that in mind as I assign small, large, deep, superficial proposals. And that’s it. I once wrote some code¹ to run statistics on the proposal project to help me pick shepherds, but it is very slow and I haven't been using it in a long time. It’s not a great way to assign shepherds. Here is a better way: All committee members tend to have an eye on incoming proposals and engage early with those that they care about, and voluntarily say that they _want_ to shepherd a particular proposal, so when it is submitted, I don't have to make any more arbitrary choices :-) Cheers, Joachim ¹ https://github.com/nomeata/ghc-proposals-stats -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/