- ghc-steering-committee

GHC Proposals session at Haskell Symposium at ICFP
by Joachim Breitner 30 Aug '22

30 Aug '22

Hello Committee and all else who follow this list, this year’s Haskell Symposium will host a special “GHC Proposals session” where current, future and past GHC Proposals can be presented and discussed: https://icfp22.sigplan.org/home/haskellsymp-2022#GHC-Proposals-Session I invite all GHC Proposal authors (or otherwise interested party) who are in Ljubljana to present your ideas and plans; just e-mail me if you want a slot. I also invite all committee members who are around to join, this is a great way to learn more about the proposals and have a real face-to- face discussion about them. (Committee members who also author proposals ideally do both :-)) I know this is rather short notice, but I still hope we can source some presentations and make this a productive meeting. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Please review #532: Clean up implicit binding, Shepherd: Arnaud
by Joachim Breitner 23 Aug '22

23 Aug '22

Dear Committee, Clean up and simplify the treatment of implicit binding have been submitted by John Ericson https://github.com/ghc-proposals/ghc-proposals/pull/532 https://github.com/Ericson2314/ghc-proposals/blob/type-variables/proposals/… This is a refinement of Modern Scoped Type variables (#448), where John believe we have left some things undone. Hence I’d like to ask Arnaud to also shepherd this one. Note that John’s #532 actually makes edits to a few existing proposals (#425, #448, #523) to clean them up; the linked proposal above explains and summarizes the changes, but also note the full diff of the PR. 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/

1 0

GHC Steering Committee Status
by Joachim Breitner 19 Aug '22

19 Aug '22

Dear Committee, let’s do another bimonthly status update . It seems that the last two months were quite quiet on the mailing list, but we did get a bunch of new submissions. Time to get active again! So what has happened since the last one? * PSA: You make my life when preparing these reports easier if every state change comes with a (small) email to the list. In particular sending a proposal back for revision is often not noted on the list. * we were asked to review these proposals: #511 Deep Subsumption, Shephard: Arnaud #330 Decorate exceptions with backtrace information, Shepherd: Vladislav #518 Type vs Constraint proposal, Shepherd: Eric #515 Relaxing HasField constraints, Shepherd: Tom #517 Require implementors before proposal submission, Shepherd: Simon PJ #522 Or Patterns, Shepherd: Richard #516 Introduce `-Wincomplete-record-selectors`, Shepherd: Eric * I reassigned the following proposal #500: Add implicit import proposal, New Shepherd: Simon M. * we have a recommendation from the shepherd about: #518 Type vs Constraint proposal (accept) #517 Require implementors before proposal submission (accept) #515 Relaxing HasField constraints (accept) #511 Deep Subsumption (accept) * we have sent the following proposals back to revision #330 Decorate exceptions with backtrace information #473: First-class existential types #454: Custom type warnings * we decided about the following proposals #448 Modern Scoped Type Variables (accept) #518 Type vs Constraint proposal (accept) (merge still pending a ✓ from Richard) #496 Nothing {} (acccept) #511 Deep Subsumption (accept) We currently have to act on the following 6 proposals, same number as last time. ## Waiting for committee decision #515 Relaxing HasField constraints 2022-08-01: Assigned to Tom 2022-08-10: Tom suggests acceptance No comments so far. Please voice your opinions! #517: Require implementors before proposal submission, Shepherd Simon 2022-08-01: Assigned to Simon 2022-08-05: Simon suggests acceptance Only supporting comments so far. ## 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 2022-08-01: Re-assignd to Simon #522: Or Patterns 2022-08-08: Assigned to Richard #516: Introduce `-Wincomplete-record-selectors`, Shepherd: Eric 2022-08-14: Assigned to Eric Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

2 1

Please review #522: Or Patterns, Shepherd: Richard
by Joachim Breitner 09 Aug '22

09 Aug '22

Dear Committee, Or Patterns have been submitted by David Knothe, Ömer Sinan Ağacan, Sebastian Graf https://github.com/ghc-proposals/ghc-proposals/pull/522 https://github.com/knothed/ghc-proposals/blob/master/proposals/0522-or-patt… It even lists implementors, in what we’d call vorauseilender Gehorsam in German! I suggest that Richard 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(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

How I pick shepherds
by Joachim Breitner 03 Aug '22

03 Aug '22

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+la… https://github.com/ghc-proposals/ghc-proposals/pulls?q=is%3Aopen+is%3Apr+la… 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(a)joachim-breitner.de http://www.joachim-breitner.de/

2 1

Please review #515: Relaxing HasField constraints, Shepherd: Tom
by Joachim Breitner 01 Aug '22

01 Aug '22

Dear Committee, Relaxing HasField constraints has been submitted by Ollie Charles https://github.com/ghc-proposals/ghc-proposals/pull/515 https://github.com/ocharles/ghc-proposals/blob/hasfield/proposals/0000-hasf… I suggest that Tom 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(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Vacation
by Joachim Breitner 14 Jul '22

14 Jul '22

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(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

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