- ghc-steering-committee

Modern Scoped Type Variables #448: recommendation (mostly) accept
by Spiwack, Arnaud 11 Jul '22

11 Jul '22

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

6 20

Re: [ghc-steering-committee] Mind the gap
by Richard Eisenberg 06 Jul '22

06 Jul '22

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 <chris(a)chrisdornan.com> 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 <lists(a)richarde.dev <mailto:lists@richarde.dev>> 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 <chris(a)chrisdornan.com <mailto:chris@chrisdornan.com>> wrote: > > > > Quick quiz: the below Haskell2010 ‘Phantoms' module (also in this Gist: https://gist.github.com/cdornan/f75cd8024434d998c87610cbb7fb6ab3 <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(a)haskell.org <mailto:ghc-steering-committee@haskell.org> > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee> >

4 12

Mind the gap
by Chris Dornan 05 Jul '22

05 Jul '22

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

2 2

Please review #496: Nothing {}, Shepherd: Eric
by Joachim Breitner 29 Jun '22

29 Jun '22

Dear Committee, Empty records with {} have been proposed by John Ericsson https://github.com/ghc-proposals/ghc-proposals/pull/496 https://github.com/Ericson2314/ghc-proposals/blob/empty-record-wildcards/pr… This seems to be about straightening a corner case, so to say. I suggest Eric as the shepherd. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Thanks, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

6 6

Please review: #454 Custom type warnings
by Tom Harding 25 Jun '22

25 Jun '22

Hi all, As Joachim noted, #454 <https://github.com/ghc-proposals/ghc-proposals/pull/454> is extracted from Adam’s previous efforts with the Unsatisfiable constraint <https://github.com/ghc-proposals/ghc-proposals/pull/433> proposal (which has since been accepted). In short, it covers an interface for custom warnings, and I can already think of plenty of ways I’d use it. I’d therefore like to recommend acceptance, and discuss any issues or changes. Thanks, Tom

6 9

GHC Steering Committee Status
by Joachim Breitner 14 Jun '22

14 Jun '22

Dear Committee, it’s about time for my ~monthly~ ~quarterly~ bimonthly status update So what has happened since the last one? * I proposed that we proposals upon submission ought to have some indication that there is someone willing and able to implement it, please join the discussion on https://github.com/ghc-proposals/ghc-proposals/pull/517 * we were asked to review these proposals: #500: Add implicit import proposal, Shepherd: Baldur #473: First-class existential types, Shepherd: Simon PJ #496: Nothing {}, Shepherd: Eric * we have a recommendation from the shepherd about: #496: Nothing {}, rec: accept * we have sent the following proposals back to revision none, it seems * we decided about the following proposals #451: Sized literals proposal (accept) We currently have to act on the following 6 proposals, up 2 since last update: ## Waiting for committee decision #454: Custom type warnings, Shepherd: Tom 2022-01-13: Recommendation to accept 2022-06-01: Arnaud says objections are minor. Tom, do you think we have consensus here? #448: Modern Scoped Type Variables, Shepherd: Arnaud 2022-03-29: Arnaud makes a non-comprehensive recommendation 2022-06-07: Ongoing discussion #496: Nothing {}, Shepherd: Eric 2022-06-12: Eric suggests acceptance ## Waiting for Shepherd action #270: Support pun-free code, Shepherd: Chris 2022-01-01: Assigned to Chris Chris, kindly please leap into action! #500: Add implicit import proposal, Shepherd: Baldur 2022-05-05: Assignd to Baldur #473: First-class existential types, Shepherd: Simon PJ 2022-05-16: Assigned to Simon Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

2 2

Please review #473: First-class existential types, Shepherd: Simon PJ
by Joachim Breitner 07 Jun '22

07 Jun '22

Dear Committee, First-class existential types has been submitted by Richard https://github.com/ghc-proposals/ghc-proposals/pull/374 https://github.com/goldfirere/ghc-proposals/blob/existentials/proposals/047… Exciting stuff! This feels, at least to me, like a proposal with major implications – not least because I believe it means that type equality will now involve some form of term equivalence, and may thus affect what kind of Core transformations are still type-preserving. Therefore I would suggest Simon PJ to shepherd 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(a)joachim-breitner.de http://www.joachim-breitner.de/

2 1

Any future plans for HasField redesign?
by John Walker 12 May '22

12 May '22

Hello Committee, I was wondering if there are any near to middle term plans to move forward with hasField redesign which I believe is an enabler for setter with record dot syntax. The ticket ( https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3257) has a milestone of 9.4.1 and it looks like the proposal is done ( https://github.com/adamgundry/ghc-proposals/blob/hasfield-redesign/proposal…) pending feedback some time ago but hasn't got to discussions yet ( https://github.com/ghc-proposals/ghc-proposals/pull/0) thanks John

2 1

Please review #451: Sized literals proposal; Shepherd: Simon M
by Richard Eisenberg 23 Apr '22

23 Apr '22

Dear Committee, This is your interim secretary speaking: Sized literals proposal, proposing syntax for literals for the new sized primitive numeric types, has been proposed by Sylvain Henry. https://github.com/ghc-proposals/ghc-proposals/pull/451 https://github.com/hsyl20/ghc-proposals/blob/sized-literals/proposals/0000-… I propose Simon M as the shepherd. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Thanks, Richard

4 4

GHC Steering Committee Status
by Joachim Breitner 07 Apr '22

07 Apr '22

Dear Committee, it’s about time for my ~monthly~ quarterly status update So what has happened since the last one? * We decided 7 proposals since then. That’s pretty good! * Simon suggested a better way to keep tabs on what’s going on, and you’ll find the second half of this mail at https://github.com/ghc-proposals/ghc-proposals/wiki/Status As before, I still didn’t get around to mess with markdown tables etc… Maybe I just don’t feel the itch enough. * Membership changes! Alejandro has stepped down, Vitaly rotated out and Baldur and Chris joined. Bladur and Chris, you have been quite quiet here so far. Make yourself heard! * we were asked to review these proposals: #454: Custom type warnings (shepherd: Tom) #448: Modern Scoped Type Variables (shepherd: Arnaud) #270: Support pun-free code (resubmission; shepherd: Vitaly, later Chris) #475: New tuple and list syntax (resubmission; shepherd: Vlad) #277: Unicode ellipsis (shepherd: Joachim) * we have a recommendation from the shepherd about: #460: migration plan for non-magical-~ (rec: accept) #451: sized literals (rec: accept) #454: Custom type warnings (rec: accept) #475: New tuple and list syntax (rec: accept) #277: Unicode ellipsis (rec: accept) #425: invisible binders in type decls (rec: accept) #448: Modern Scoped Type Variables (rec: mostly accept) * we have sent the following proposals back to revision none, it seems * we decided about the following proposals #319: NoFallibleDo (reject) #392: Clarify modifiers design principle (accept) #460: migration plan for non-magical-~ (accept) #475: New tuple and list syntax (accept) #277: Unicode ellipsis (accept) #452: Articulate principles for GHC evolution (accept) #425: invisible binders in type declarations (accept) We currently have to act on the following 4 proposals, down by 2 since last update: ## Waiting for committee decision #451: Sized Literals, Shepherd: Simon M. 2022-01-11: Recommendation to accept by Simon Simon asked the committee for the color of the shed! Please all weigh in! #454: Custom type warnings, Shepherd: Tom 2022-01-13: Recommendation to accept There was contention (by Vlad) if the possible performance impact is too bad, with a bit of active discussion on Github #448: Modern Scoped Type Variables, Shepherd: Arnaud 2022-03-29: Arnaud makes a non-comprehensive recommendation Ongoing discussion about which parts should be accepted and which not (yet). Thanks Arnaud, for guiding the discussion. ## Waiting for Shepherd action #270: Support pun-free code, Shepherd: Chris 2022-01-01: Assigned to Chris Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0