From mail at joachim-breitner.de Mon Aug 1 06:42:53 2022 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 01 Aug 2022 08:42:53 +0200 Subject: [ghc-steering-committee] Please review #515: Relaxing HasField constraints, Shepherd: Tom Message-ID: 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-hasfield-incoherence.rst 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 at joachim-breitner.de http://www.joachim-breitner.de/ From mail at joachim-breitner.de Mon Aug 1 06:45:34 2022 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 01 Aug 2022 08:45:34 +0200 Subject: [ghc-steering-committee] Please review #500: Add implicit import proposal, New Shepherd: Simon M. In-Reply-To: <035c69c81b6fe9921600c053e2ee919b62e1837a.camel@joachim-breitner.de> References: <035c69c81b6fe9921600c053e2ee919b62e1837a.camel@joachim-breitner.de> Message-ID: <5ef21ee8fbe9a215b87efcb56cec578a22399200.camel@joachim-breitner.de> Dear Committee, Add implicit import proposal has been submitted by Tristan de Cacqueray This is an interesting one: At first glance it looks quite un- haskellish, but it’s hard to poing out what’s, if anything, is wrong with it. I expect that the discussion will revolve not so much about technical issues, but more about best practices and our vision for Haskell’s look and feel. https://github.com/ghc-proposals/ghc-proposals/pull/500 https://github.com/TristanCacqueray/ghc-proposals/blob/implicit-import/proposals/0000-implicit-import.rst I originally assigned this to Baldur in May, but we haven't heard from you. To be considerate of the proposal author’s motivation, I’d like to re-assign this to Simon Marlow. 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 mail at joachim-breitner.de Mon Aug 1 06:49:54 2022 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 01 Aug 2022 08:49:54 +0200 Subject: [ghc-steering-committee] Please review #517: Require implementors before proposal submission, Shepherd: Simon PJ Message-ID: Dear Committee, I have submitted a meta-proposal to require implementors to be named before proposal submission, to focus on those proposals that are likely to be actually implemented. https://github.com/ghc-proposals/ghc-proposals/pull/517 Because this is a process-related proposal, I’d like to ask Simon to shepherd it. 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 Tue Aug 2 20:48:09 2022 From: lists at richarde.dev (Richard Eisenberg) Date: Tue, 2 Aug 2022 20:48:09 +0000 Subject: [ghc-steering-committee] How I pick shepherds In-Reply-To: <4af2d38b2efb8f7342fe6605de59388cbe4383cc.camel@joachim-breitner.de> References: <4af2d38b2efb8f7342fe6605de59388cbe4383cc.camel@joachim-breitner.de> Message-ID: <010f01826050e252-10fb4051-40a2-4ee1-a9f4-2cde37b67fd9-000000@us-east-2.amazonses.com> But this is an algorithm! It just has subjective components. :) Indeed I guessed at much of this, including opening up those links. What I didn't have is a good way of knowing what members had recently shepherded, and so I couldn't do load-balancing. For my part, I think the current algorithm is good and does not need refinement. Some of us are naturally more inclined to keep up with this kind of work, and thus expecting shepherds to always volunteer themselves will lead to an effectively smaller committee, which is not what we want. Thanks for laying this out! Richard > On Jul 29, 2022, at 4:24 PM, Joachim Breitner wrote: > > 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/ > > _______________________________________________ > 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 simon.peytonjones at gmail.com Thu Aug 4 23:02:20 2022 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Fri, 5 Aug 2022 00:02:20 +0100 Subject: [ghc-steering-committee] Please review #517: Require implementors before proposal submission, Shepherd: Simon PJ In-Reply-To: References: Message-ID: Dear committee, See https://github.com/ghc-proposals/ghc-proposals/pull/517 Joachim suggests that a prerequisite for submitting a proposal to the committee is that someone is offering to implement it. - This would avoid us spending precious cycles debating a proposal that no one is going to implement. - An offer of implementation cannot be binding, so it is something of a soft constraint. (An author could cynically volunteer themselves, without having any intention of carrying through, but we expect better of the Haskell community.) - We should stress that nothing stops someone creating a proposal, making a PR, and debating it with the community, all without an implementor. Only when it is submitted to the committee for review and approval is an implementor required. - Joachim suggests that this replaces the (never used) "Endorsements" section. I wonder if a proposal that is accepted but not implemented (for whatever reason) should be un-accepted after, say, a year. That would provide some incentive to get on with it; and the language context might be different by then. I suggest that we debate the principle first. I have a few word-smithing suggestions, but principles first! On balance I recommend acceptance, with the above nuances clarified. Simon On Mon, 1 Aug 2022 at 07:50, Joachim Breitner wrote: > Dear Committee, > > I have submitted a meta-proposal to require implementors to be named > before proposal submission, to focus on those proposals that are likely > to be actually implemented. > > https://github.com/ghc-proposals/ghc-proposals/pull/517 > > Because this is a process-related proposal, I’d like to ask Simon to > shepherd it. > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at richarde.dev Fri Aug 5 12:34:38 2022 From: lists at richarde.dev (Richard Eisenberg) Date: Fri, 5 Aug 2022 12:34:38 +0000 Subject: [ghc-steering-committee] Please review #517: Require implementors before proposal submission, Shepherd: Simon PJ In-Reply-To: References: Message-ID: <010f01826e0021e3-55dae02e-af8c-4f09-93c8-d2cf4c5c0cf6-000000@us-east-2.amazonses.com> I support this proposal. Having many accepted but unimplemented proposals is not a good look. If need be, we can create a ready-for-submission-but-lacking-implementor label so that potential contributors can find ideas, but I favor waiting for a demand before creating that structure. Simon's idea of un-accepting proposals is interesting, but should probably not get tucked into this idea. Richard > On Aug 4, 2022, at 7:02 PM, Simon Peyton Jones wrote: > > Dear committee, > > See https://github.com/ghc-proposals/ghc-proposals/pull/517 > > Joachim suggests that a prerequisite for submitting a proposal to the committee is that someone is offering to implement it. > This would avoid us spending precious cycles debating a proposal that no one is going to implement. > An offer of implementation cannot be binding, so it is something of a soft constraint. (An author could cynically volunteer themselves, without having any intention of carrying through, but we expect better of the Haskell community.) > We should stress that nothing stops someone creating a proposal, making a PR, and debating it with the community, all without an implementor. Only when it is submitted to the committee for review and approval is an implementor required. > Joachim suggests that this replaces the (never used) "Endorsements" section. > I wonder if a proposal that is accepted but not implemented (for whatever reason) should be un-accepted after, say, a year. That would provide some incentive to get on with it; and the language context might be different by then. > > I suggest that we debate the principle first. I have a few word-smithing suggestions, but principles first! > > On balance I recommend acceptance, with the above nuances clarified. > > Simon > > On Mon, 1 Aug 2022 at 07:50, Joachim Breitner > wrote: > Dear Committee, > > I have submitted a meta-proposal to require implementors to be named > before proposal submission, to focus on those proposals that are likely > to be actually implemented. > > https://github.com/ghc-proposals/ghc-proposals/pull/517 > > Because this is a process-related proposal, I’d like to ask Simon to shepherd it. > > 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 chris at chrisdornan.com Sat Aug 6 11:21:53 2022 From: chris at chrisdornan.com (Chris Dornan) Date: Sat, 6 Aug 2022 12:21:53 +0100 Subject: [ghc-steering-committee] Please review #517: Require implementors before proposal submission, Shepherd: Simon PJ In-Reply-To: <010f01826e0021e3-55dae02e-af8c-4f09-93c8-d2cf4c5c0cf6-000000@us-east-2.amazonses.com> References: <010f01826e0021e3-55dae02e-af8c-4f09-93c8-d2cf4c5c0cf6-000000@us-east-2.amazonses.com> Message-ID: I wouldn’t worry too much about the optics of approving proposals that don’t get implemented — if that were the only issue I wouldn’t object to having a heap of proposals ready to be implemented by a keen implementor. Healthy backlogs are better than the alternative in my view. Having proposals in the twilight zone, absorbing committee time and frustrating proposers that are never likely to get implemented is not good and this proposal should help with that so I support it. Chris > On 2022-08-05, at 13:34, Richard Eisenberg wrote: > > I support this proposal. Having many accepted but unimplemented proposals is not a good look. If need be, we can create a ready-for-submission-but-lacking-implementor label so that potential contributors can find ideas, but I favor waiting for a demand before creating that structure. > > Simon's idea of un-accepting proposals is interesting, but should probably not get tucked into this idea. > > Richard > >> On Aug 4, 2022, at 7:02 PM, Simon Peyton Jones wrote: >> >> Dear committee, >> >> See https://github.com/ghc-proposals/ghc-proposals/pull/517 >> >> Joachim suggests that a prerequisite for submitting a proposal to the committee is that someone is offering to implement it. >> • This would avoid us spending precious cycles debating a proposal that no one is going to implement. >> • An offer of implementation cannot be binding, so it is something of a soft constraint. (An author could cynically volunteer themselves, without having any intention of carrying through, but we expect better of the Haskell community.) >> • We should stress that nothing stops someone creating a proposal, making a PR, and debating it with the community, all without an implementor. Only when it is submitted to the committee for review and approval is an implementor required. >> • Joachim suggests that this replaces the (never used) "Endorsements" section. >> I wonder if a proposal that is accepted but not implemented (for whatever reason) should be un-accepted after, say, a year. That would provide some incentive to get on with it; and the language context might be different by then. >> >> I suggest that we debate the principle first. I have a few word-smithing suggestions, but principles first! >> >> On balance I recommend acceptance, with the above nuances clarified. >> >> Simon >> >> On Mon, 1 Aug 2022 at 07:50, Joachim Breitner wrote: >> Dear Committee, >> >> I have submitted a meta-proposal to require implementors to be named >> before proposal submission, to focus on those proposals that are likely >> to be actually implemented. >> >> https://github.com/ghc-proposals/ghc-proposals/pull/517 >> >> Because this is a process-related proposal, I’d like to ask Simon to shepherd it. >> >> 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 > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From mail at joachim-breitner.de Mon Aug 8 19:09:24 2022 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 08 Aug 2022 21:09:24 +0200 Subject: [ghc-steering-committee] Please review #522: Or Patterns, Shepherd: Richard Message-ID: 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-patterns.rst 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 at joachim-breitner.de http://www.joachim-breitner.de/ From i.am.tom.harding at gmail.com Wed Aug 10 10:58:21 2022 From: i.am.tom.harding at gmail.com (Tom Harding) Date: Wed, 10 Aug 2022 11:58:21 +0100 Subject: [ghc-steering-committee] Please review: #515 Relaxing HasField constraints Message-ID: <5F4E7390-2196-4FAA-926E-506141F4D487@gmail.com> Hi all, Ollie Charles’ proposal removes the restrictions placed on HasField instances. Close to my heart, this addresses the problem of creating custom `HasField` instances for record types. I’m in favour of this proposal as it would solve some issues I have encountered, but the floor is open for discussion. Thanks, Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Sun Aug 14 17:01:49 2022 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sun, 14 Aug 2022 19:01:49 +0200 Subject: [ghc-steering-committee] Please review #516: Introduce `-Wincomplete-record-selectors`, Shepherd: Eric Message-ID: <5e616addb7390649422195311e6a70b7e5ee3306.camel@joachim-breitner.de> Dear Committee, Introduce `-Wincomplete-record-selectors` have been submitted by Adam Gundry https://github.com/ghc-proposals/ghc-proposals/pull/516 https://github.com/adamgundry/ghc-proposals/blob/incomplete-record-selectors/proposals/0000-incomplete-record-selectors.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 mail at joachim-breitner.de Fri Aug 19 08:44:08 2022 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 19 Aug 2022 10:44:08 +0200 Subject: [ghc-steering-committee] Please review #517: Require implementors before proposal submission, Shepherd: Simon PJ In-Reply-To: References: <010f01826e0021e3-55dae02e-af8c-4f09-93c8-d2cf4c5c0cf6-000000@us-east-2.amazonses.com> Message-ID: <478fe508de4fe7eb2f3c9cd6a5a30a21deed1772.camel@joachim-breitner.de> Hi, Simon, Richad and Chris in support. Any other opinions? Or should I just merge this? Cheers, Joachim Am Samstag, dem 06.08.2022 um 12:21 +0100 schrieb Chris Dornan: > I wouldn’t worry too much about the optics of approving proposals that don’t get implemented — if that were the only issue I wouldn’t object to having a heap of proposals ready to be implemented by a keen implementor. Healthy backlogs are better than the alternative in my view. > > Having proposals in the twilight zone, absorbing committee time and frustrating proposers that are never likely to get implemented is not good and this proposal should help with that so I support it. > > Chris > > > On 2022-08-05, at 13:34, Richard Eisenberg wrote: > > > > I support this proposal. Having many accepted but unimplemented proposals is not a good look. If need be, we can create a ready-for-submission-but-lacking-implementor label so that potential contributors can find ideas, but I favor waiting for a demand before creating that structure. > > > > Simon's idea of un-accepting proposals is interesting, but should probably not get tucked into this idea. > > > > Richard > > > > > On Aug 4, 2022, at 7:02 PM, Simon Peyton Jones wrote: > > > > > > Dear committee, > > > > > > See https://github.com/ghc-proposals/ghc-proposals/pull/517 > > > > > > Joachim suggests that a prerequisite for submitting a proposal to the committee is that someone is offering to implement it. > > > • This would avoid us spending precious cycles debating a proposal that no one is going to implement. > > > • An offer of implementation cannot be binding, so it is something of a soft constraint. (An author could cynically volunteer themselves, without having any intention of carrying through, but we expect better of the Haskell community.) > > > • We should stress that nothing stops someone creating a proposal, making a PR, and debating it with the community, all without an implementor. Only when it is submitted to the committee for review and approval is an implementor required. > > > • Joachim suggests that this replaces the (never used) "Endorsements" section. > > > I wonder if a proposal that is accepted but not implemented (for whatever reason) should be un-accepted after, say, a year. That would provide some incentive to get on with it; and the language context might be different by then. > > > > > > I suggest that we debate the principle first. I have a few word-smithing suggestions, but principles first! > > > > > > On balance I recommend acceptance, with the above nuances clarified. > > > > > > Simon > > > > > > On Mon, 1 Aug 2022 at 07:50, Joachim Breitner wrote: > > > Dear Committee, > > > > > > I have submitted a meta-proposal to require implementors to be named > > > before proposal submission, to focus on those proposals that are likely > > > to be actually implemented. > > > > > > https://github.com/ghc-proposals/ghc-proposals/pull/517 > > > > > > Because this is a process-related proposal, I’d like to ask Simon to shepherd it. > > > > > > 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 > > > > _______________________________________________ > > 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 -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From mail at joachim-breitner.de Fri Aug 19 09:15:40 2022 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 19 Aug 2022 11:15:40 +0200 Subject: [ghc-steering-committee] GHC Steering Committee Status Message-ID: 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 at joachim-breitner.de http://www.joachim-breitner.de/ From chris at chrisdornan.com Fri Aug 19 09:26:35 2022 From: chris at chrisdornan.com (Chris Dornan) Date: Fri, 19 Aug 2022 10:26:35 +0100 Subject: [ghc-steering-committee] GHC Steering Committee Status In-Reply-To: References: Message-ID: Joachim, thanks ever so much for all of this — humbled. I am sorry — I missed being formally assigned to #270 (pun-free code) — I will endeavour to do better and pick up the ball. > On 19 Aug 2022, at 10:15, Joachim Breitner wrote: > > 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 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 lists at richarde.dev Fri Aug 19 18:48:15 2022 From: lists at richarde.dev (Richard Eisenberg) Date: Fri, 19 Aug 2022 18:48:15 +0000 Subject: [ghc-steering-committee] Please review #517: Require implementors before proposal submission, Shepherd: Simon PJ In-Reply-To: <478fe508de4fe7eb2f3c9cd6a5a30a21deed1772.camel@joachim-breitner.de> References: <010f01826e0021e3-55dae02e-af8c-4f09-93c8-d2cf4c5c0cf6-000000@us-east-2.amazonses.com> <478fe508de4fe7eb2f3c9cd6a5a30a21deed1772.camel@joachim-breitner.de> Message-ID: <010f0182b76f35dd-6cb751ee-faf3-4af5-8119-6e66ef1ef576-000000@us-east-2.amazonses.com> > On Aug 19, 2022, at 4:44 AM, Joachim Breitner wrote: > > Simon, Richad and Chris in support. Any other opinions? Or should I > just merge this? It would be Really Nice to have more opinions on this one. It's a substantial change to our workflow, and I would expect a move like this to be best with a solid majority of us actively in favor (which I am). Can the other voices join the conversation, please? Thanks, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at richarde.dev Fri Aug 19 21:23:21 2022 From: lists at richarde.dev (Richard Eisenberg) Date: Fri, 19 Aug 2022 21:23:21 +0000 Subject: [ghc-steering-committee] Proposal #522: Or patterns. Recommendation: accept Message-ID: <010f0182b7fd3756-e5122221-8aa8-42ee-a12e-1841ac772f83-000000@us-east-2.amazonses.com> Hi all, I have been assigned to shepherd Proposal #522, Or patterns. Proposal text: https://github.com/knothed/ghc-proposals/blob/master/proposals/0522-or-patterns.rst Proposal discussion: https://github.com/ghc-proposals/ghc-proposals/pull/522 The proposal introduces a syntax for or-patterns. Here is an example: case ... of K1 a b c -> Just ... K2 d e -> Just ... (K3 {} ; K4 {} ; K5 {}) -> Nothing Summary Without this proposal, the author of the above code would have to either use a _ pattern for the last line, meaning that future new constructors added to the datatype would go unreported by compiler warnings, or to write the K3, K4, and K5 cases separately, repeating the right-hand side. Or-patterns are common in other languages. The authors include a nice section (https://github.com/knothed/ghc-proposals/blob/master/proposals/0522-or-patterns.rst#id12) on alternative syntax. I recommend reading it; it made me feel better about the proposed semi-colon syntax. The proposal requires that each pattern in an or-pattern must not bind any variables. Any provided contexts (e.g. GADT equalities) and existential variables are ignored, and any required context is combined across the disjuncts in the pattern. Two implementors are named in the proposal. Recommendation I recommend acceptance. This proposal is relatively simple, will lead to a nice quality-of-life improvement, is future-compatible (*) with or-patterns that do bind variables/contexts/existentials, and has a natural reading to users unfamiliar with the extension. (*): I suppose that the fact that an or-pattern discards equalities might mean that a later improvement that retains these equalities might interfere with type inference (because in-scope equalities cause type variables to become untouchable). But I will choose not to worry about this. The downsides are: - Yet another feature to think about, including a new extension name. - Yet another feature to implement and maintain. I think the improvements to the language are worth these downsides, though I could be convinced otherwise. Please let me know what you think about this proposal. I'm hoping to accept this proposal in three weeks (a bit longer than my usual timeframe, due to it being a popular time for holidays), unless there is objection. Thanks! Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.spiwack at tweag.io Tue Aug 23 08:54:14 2022 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Tue, 23 Aug 2022 10:54:14 +0200 Subject: [ghc-steering-committee] Please review: #515 Relaxing HasField constraints In-Reply-To: <5F4E7390-2196-4FAA-926E-506141F4D487@gmail.com> References: <5F4E7390-2196-4FAA-926E-506141F4D487@gmail.com> Message-ID: I don't have much of an opinion on this proposal. I do believe that, in the current state, it doesn't discuss in sufficient detail about whether instances should be considered coherent or not by the compiler. This seems to be the most non-trivial choice in the proposal. I've asked for an addition to that respect on the Github thread. On Wed, Aug 10, 2022 at 12:58 PM Tom Harding wrote: > Hi all, > > Ollie Charles’ proposal > removes the > restrictions placed on HasField instances. Close to my heart, this > addresses the problem of creating custom `HasField` instances for record > types. I’m in favour of this proposal as it would solve some issues I have > encountered, but the floor is open for discussion. > > Thanks, > Tom > _______________________________________________ > 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 Aug 23 09:09:41 2022 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Tue, 23 Aug 2022 11:09:41 +0200 Subject: [ghc-steering-committee] Please review #517: Require implementors before proposal submission, Shepherd: Simon PJ In-Reply-To: <010f0182b76f35dd-6cb751ee-faf3-4af5-8119-6e66ef1ef576-000000@us-east-2.amazonses.com> References: <010f01826e0021e3-55dae02e-af8c-4f09-93c8-d2cf4c5c0cf6-000000@us-east-2.amazonses.com> <478fe508de4fe7eb2f3c9cd6a5a30a21deed1772.camel@joachim-breitner.de> <010f0182b76f35dd-6cb751ee-faf3-4af5-8119-6e66ef1ef576-000000@us-east-2.amazonses.com> Message-ID: I'm rather in the “against” camp, for now. I'm fine with accepting designs without necessarily an implementer attached to them. At least a priori. But I don't really have data: how many unimplemented proposals do we have? What do other communities do? (say Rust, Ocaml, who both have a proposal process). So maybe I can be convinced. /Arnaud On Fri, Aug 19, 2022 at 8:48 PM Richard Eisenberg wrote: > > > On Aug 19, 2022, at 4:44 AM, Joachim Breitner > wrote: > > Simon, Richad and Chris in support. Any other opinions? Or should I > just merge this? > > > It would be Really Nice to have more opinions on this one. It's a > substantial change to our workflow, and I would expect a move like this to > be best with a solid majority of us actively in favor (which I am). > > Can the other voices join the conversation, please? > > Thanks, > Richard > _______________________________________________ > 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 Tue Aug 23 09:50:59 2022 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 23 Aug 2022 11:50:59 +0200 Subject: [ghc-steering-committee] Please review #532: Clean up implicit binding, Shepherd: Arnaud Message-ID: 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/0532-type-variable-scoping.rst 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 at joachim-breitner.de http://www.joachim-breitner.de/ From arnaud.spiwack at tweag.io Tue Aug 23 10:17:02 2022 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Tue, 23 Aug 2022 12:17:02 +0200 Subject: [ghc-steering-committee] Proposal #522: Or patterns. Recommendation: accept In-Reply-To: <010f0182b7fd3756-e5122221-8aa8-42ee-a12e-1841ac772f83-000000@us-east-2.amazonses.com> References: <010f0182b7fd3756-e5122221-8aa8-42ee-a12e-1841ac772f83-000000@us-east-2.amazonses.com> Message-ID: I'm quite positive about the proposal. I think it's an exaggeration to claim, as the proposal kind of does, that or-patterns that don't bind variables cover 90% of the use-cases of or-patterns. This has not been my experience. On the other hand, it's perfectly fine to start there and improve later. I've also asked for some minor precisions in the Github threads. Richard, concerning your worry that you are not worrying about: Ocaml also has GADTs and or-patterns, it doesn't retain equalities in or-patterns. So if this future exists, it is probably quite far away. On Fri, Aug 19, 2022 at 11:23 PM Richard Eisenberg wrote: > Hi all, > > I have been assigned to shepherd Proposal #522, Or patterns. > > Proposal text: > https://github.com/knothed/ghc-proposals/blob/master/proposals/0522-or-patterns.rst > Proposal discussion: > https://github.com/ghc-proposals/ghc-proposals/pull/522 > > The proposal introduces a syntax for or-patterns. Here is an example: > > case ... of > K1 a b c -> Just ... > K2 d e -> Just ... > (K3 {} ; K4 {} ; K5 {}) -> Nothing > > *Summary* > > Without this proposal, the author of the above code would have to either > use a _ pattern for the last line, meaning that future new constructors > added to the datatype would go unreported by compiler warnings, or to write > the K3, K4, and K5 cases separately, repeating the right-hand side. > Or-patterns are common in other languages. > > The authors include a nice section ( > https://github.com/knothed/ghc-proposals/blob/master/proposals/0522-or-patterns.rst#id12) > on alternative syntax. I recommend reading it; it made me feel better about > the proposed semi-colon syntax. > > The proposal requires that each pattern in an or-pattern must not bind any > variables. Any provided contexts (e.g. GADT equalities) and existential > variables are ignored, and any required context is combined across the > disjuncts in the pattern. > > Two implementors are named in the proposal. > > *Recommendation* > > I recommend acceptance. This proposal is relatively simple, will lead to a > nice quality-of-life improvement, is future-compatible (*) with or-patterns > that *do* bind variables/contexts/existentials, and has a natural reading > to users unfamiliar with the extension. > > (*): I suppose that the fact that an or-pattern discards equalities might > mean that a later improvement that retains these equalities might interfere > with type inference (because in-scope equalities cause type variables to > become untouchable). But I will choose not to worry about this. > > The downsides are: > - Yet another feature to think about, including a new extension name. > - Yet another feature to implement and maintain. > > I think the improvements to the language are worth these downsides, though > I could be convinced otherwise. > > Please let me know what you think about this proposal. I'm hoping to > accept this proposal in three weeks (a bit longer than my usual timeframe, > due to it being a popular time for holidays), unless there is objection. > > Thanks! > Richard > _______________________________________________ > 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 eric at seidel.io Tue Aug 23 18:01:39 2022 From: eric at seidel.io (Eric Seidel) Date: Tue, 23 Aug 2022 14:01:39 -0400 Subject: [ghc-steering-committee] Please review #517: Require implementors before proposal submission, Shepherd: Simon PJ In-Reply-To: References: <010f01826e0021e3-55dae02e-af8c-4f09-93c8-d2cf4c5c0cf6-000000@us-east-2.amazonses.com> <478fe508de4fe7eb2f3c9cd6a5a30a21deed1772.camel@joachim-breitner.de> <010f0182b76f35dd-6cb751ee-faf3-4af5-8119-6e66ef1ef576-000000@us-east-2.amazonses.com> Message-ID: I'm on the fence about this, which is partly why I've been quiet. I am sympathetic to the concern that unimplemented proposals harm morale and make it hard to keep track of what exactly the GHC Steering Committee-approved dialect of Haskell is. On the other hand, like Arnaud, I don't particularly want to block a perfectly good proposal from being accepted just because nobody has (yet) volunteered to implement it. Here are a few loose thoughts on the matter: * Some languages (notably C/C++) separate the language specification from implementation. The Standards Committee decides what the language looks like and follows a proposals process like ours, and then the various compilers are expected to add support for new language standards. Of course you also have compiler authors represented on the Standards Committee to provide feedback on the feasibility of proposals, but the formal separation of powers remains. With this formal separation, the question of requiring volunteers to implement doesn't really make sense. * Other languages like Python follow more of a "reference implementation" approach. There may still be a language specification, but it co-evolves with the main implementation. In this world requiring a volunteer to implement is a plausible restriction. * From what I understand, Rust is an interesting example. From the outside they look very much like a reference implementation, but internally I believe they have separate Committees / Working Groups responsible for language specification and implementation much like the C/C++ world. * So, which world do we occupy? We have three distinct entities at play: 1. The Haskell Committee (not us) is responsible for the specification of Haskell as a language. 2. The GHC Maintainers (also not us) are responsible for the implementation and maintenance of GHC. 3. The GHC Steering Committee (us) is responsible for the specification of Haskell as implemented by GHC. The Haskell Committee clearly follows the C/C++ model of clear boundaries between specification and implementation. But they have not been very active for a while and GHC has in many ways become a reference implementation for Haskell. I think that was part of the motivation for establishing our Committee, to re-establish more of a separation between specification and implementation. Given that backdrop, I feel more inclined to side against the current proposal. Perhaps rather than requiring an implementor to volunteer, we should lean more on groups like the Haskell Foundation to *fund the implementation of proposals*? Eric On Tue, Aug 23, 2022, at 05:09, Spiwack, Arnaud wrote: > I'm rather in the “against” camp, for now. I'm fine with accepting > designs without necessarily an implementer attached to them. At least a > priori. But I don't really have data: how many unimplemented proposals > do we have? What do other communities do? (say Rust, Ocaml, who both > have a proposal process). > > So maybe I can be convinced. > > /Arnaud > > On Fri, Aug 19, 2022 at 8:48 PM Richard Eisenberg wrote: >> >> >>> On Aug 19, 2022, at 4:44 AM, Joachim Breitner wrote: >>> >>> Simon, Richad and Chris in support. Any other opinions? Or should I >>> just merge this? >> >> It would be Really Nice to have more opinions on this one. It's a substantial change to our workflow, and I would expect a move like this to be best with a solid majority of us actively in favor (which I am). >> >> Can the other voices join the conversation, please? >> >> Thanks, >> Richard >> _______________________________________________ >> 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 From eric at seidel.io Tue Aug 23 18:13:57 2022 From: eric at seidel.io (Eric Seidel) Date: Tue, 23 Aug 2022 14:13:57 -0400 Subject: [ghc-steering-committee] Please review #516: Introduce `-Wincomplete-record-selectors`, Shepherd: Eric In-Reply-To: <5e616addb7390649422195311e6a70b7e5ee3306.camel@joachim-breitner.de> References: <5e616addb7390649422195311e6a70b7e5ee3306.camel@joachim-breitner.de> Message-ID: <35395b03-ba60-4d4d-8c40-f1bb66d8845a@www.fastmail.com> Dear Committee, Adam Gundry has proposed a new warning -Wincomplete-record-selectors[1] that would flag occurrences of partial record selectors, e.g. the field `x` in ``` data T = T1 { x :: Int, y :: Bool } | T2 { y :: Bool } ``` The proposal is well-specified, will never warn about total selectors (e.g. `y` above), and allows for a smarter compiler to suppress warnings in cases where a partial selector is used in a total context (e.g. `x (T1 42 True)`). I recommend acceptance. [1]: https://github.com/ghc-proposals/ghc-proposals/pull/516 On Sun, Aug 14, 2022, at 13:01, Joachim Breitner wrote: > Dear Committee, > > Introduce `-Wincomplete-record-selectors` > have been submitted by Adam Gundry > > https://github.com/ghc-proposals/ghc-proposals/pull/516 > https://github.com/adamgundry/ghc-proposals/blob/incomplete-record-selectors/proposals/0000-incomplete-record-selectors.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 Aug 24 05:47:40 2022 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Wed, 24 Aug 2022 07:47:40 +0200 Subject: [ghc-steering-committee] Please review #516: Introduce `-Wincomplete-record-selectors`, Shepherd: Eric In-Reply-To: <35395b03-ba60-4d4d-8c40-f1bb66d8845a@www.fastmail.com> References: <5e616addb7390649422195311e6a70b7e5ee3306.camel@joachim-breitner.de> <35395b03-ba60-4d4d-8c40-f1bb66d8845a@www.fastmail.com> Message-ID: The proposal makes sense to me. I don't have a strong opinion, but I'm leaning towards acceptance. On Tue, Aug 23, 2022 at 8:14 PM Eric Seidel wrote: > Dear Committee, > > Adam Gundry has proposed a new warning -Wincomplete-record-selectors[1] > that would flag occurrences of partial record selectors, e.g. the field `x` > in > > ``` > data T = T1 { x :: Int, y :: Bool } > | T2 { y :: Bool } > ``` > > The proposal is well-specified, will never warn about total selectors > (e.g. `y` above), and allows for a smarter compiler to suppress warnings in > cases where a partial selector is used in a total context (e.g. `x (T1 42 > True)`). > > I recommend acceptance. > > [1]: https://github.com/ghc-proposals/ghc-proposals/pull/516 > > On Sun, Aug 14, 2022, at 13:01, Joachim Breitner wrote: > > Dear Committee, > > > > Introduce `-Wincomplete-record-selectors` > > have been submitted by Adam Gundry > > > > https://github.com/ghc-proposals/ghc-proposals/pull/516 > > > https://github.com/adamgundry/ghc-proposals/blob/incomplete-record-selectors/proposals/0000-incomplete-record-selectors.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 chris at chrisdornan.com Wed Aug 24 06:27:20 2022 From: chris at chrisdornan.com (Chris Dornan) Date: Wed, 24 Aug 2022 07:27:20 +0100 Subject: [ghc-steering-committee] Proposal #270: Support pun-free code. Recommendation: accept Message-ID: Hi all, I have been assigned to shepherd Proposal #270: Support pun-free code Proposal text: https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-pun-free-code.md Proposal discussion: https://github.com/ghc-proposals/ghc-proposals/pull/270 The proposal helps manage @data T = T@ style definitions that use the same name for type and data constructors. It introduces -Wpuns and -Wpun-bind to warn about puns at usage and binding sites, respectively, and adds qualified import syntax for importing selectively into the data and type name spaces: import Data.Proxy type qualified as T -- import only the type namespace import Data.Proxy data qualified as D -- import only the data namespace As the low number indicates the proposal has been around for a while and the author has an implementation PR: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/2044. The most active discussion point was Simon’s observation that this extension introduces a ‘fork’ in the language: https://github.com/ghc-proposals/ghc-proposals/pull/270#issuecomment-536115565. (See Simon’s comment at the link for an explanation of the Haskell language fork idea.) There is a long tradition of using data/type constructor puns (older than Haskell itself) and many people will consider it good style (I certainly do), while others do not, and they will benefit from tools to help manage and limit their use. So, notwithstanding the fork-like nature of the proposal, because it is not very intrusive (some warnings with finer control of qualified imports), and it is helping folks to establish a subset that they are maintaining anyway, I am minded to accept this proposal — though it was close. My sole concern is that it could give rise to contentious pressure on the wider Haskell community to embrace the subset. To (avoiding) this end, I suggest that we include wording in the user guide section documenting this extension to the effect that there is no consensus on the desirability or otherwise of the punful code the extension seeks to address. Chris From simon.peytonjones at gmail.com Wed Aug 24 08:26:16 2022 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Wed, 24 Aug 2022 09:26:16 +0100 Subject: [ghc-steering-committee] Please review #517: Require implementors before proposal submission, Shepherd: Simon PJ In-Reply-To: References: Message-ID: Dear Tom, Simon, Vlad, Baldur Could you express your opinion about this proposal please? Thanks Simon On Fri, 5 Aug 2022 at 00:02, Simon Peyton Jones wrote: > Dear committee, > > See https://github.com/ghc-proposals/ghc-proposals/pull/517 > > Joachim suggests that a prerequisite for submitting a proposal to the > committee is that someone is offering to implement it. > > - This would avoid us spending precious cycles debating a proposal > that no one is going to implement. > - An offer of implementation cannot be binding, so it is something of > a soft constraint. (An author could cynically volunteer themselves, > without having any intention of carrying through, but we expect better of > the Haskell community.) > - We should stress that nothing stops someone creating a proposal, > making a PR, and debating it with the community, all without an > implementor. Only when it is submitted to the committee for review and > approval is an implementor required. > - Joachim suggests that this replaces the (never used) "Endorsements" > section. > > I wonder if a proposal that is accepted but not implemented (for whatever > reason) should be un-accepted after, say, a year. That would provide some > incentive to get on with it; and the language context might be different by > then. > > I suggest that we debate the principle first. I have a few word-smithing > suggestions, but principles first! > > On balance I recommend acceptance, with the above nuances clarified. > > Simon > > On Mon, 1 Aug 2022 at 07:50, Joachim Breitner > wrote: > >> Dear Committee, >> >> I have submitted a meta-proposal to require implementors to be named >> before proposal submission, to focus on those proposals that are likely >> to be actually implemented. >> >> https://github.com/ghc-proposals/ghc-proposals/pull/517 >> >> Because this is a process-related proposal, I’d like to ask Simon to >> shepherd it. >> >> 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 >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vlad.z.4096 at gmail.com Wed Aug 24 08:49:30 2022 From: vlad.z.4096 at gmail.com (Vladislav Zavialov (int-index)) Date: Wed, 24 Aug 2022 11:49:30 +0300 Subject: [ghc-steering-committee] Please review #517: Require implementors before proposal submission, Shepherd: Simon PJ In-Reply-To: References: Message-ID: <0A370D47-CEE0-471F-BB8E-5B9B1CA440DF@gmail.com> I am uncertain. Do we have any case studies? What are examples of proposals that were submitted without an implementor? - Vlad > On 24 Aug 2022, at 11:26, Simon Peyton Jones wrote: > > Dear Tom, Simon, Vlad, Baldur > > Could you express your opinion about this proposal please? > > Thanks > > Simon From mail at joachim-breitner.de Wed Aug 24 10:37:13 2022 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 24 Aug 2022 12:37:13 +0200 Subject: [ghc-steering-committee] Please review #517: Require implementors before proposal submission, Shepherd: Simon PJ In-Reply-To: <0A370D47-CEE0-471F-BB8E-5B9B1CA440DF@gmail.com> References: <0A370D47-CEE0-471F-BB8E-5B9B1CA440DF@gmail.com> Message-ID: <3a087b34044bd520f319450590cb7627b01d36ae.camel@joachim-breitner.de> Hi, Am Mittwoch, dem 24.08.2022 um 11:49 +0300 schrieb Vladislav Zavialov (int-index): > I am uncertain. Do we have any case studies? What are examples of > proposals that were submitted without an implementor? The list at https://github.com/ghc-proposals/ghc-proposals/pulls?page=2&q=is%3Apr+label%3A%22Accepted%22+-label%3A%22Implemented%22 lists PRs marked as accepted but not implemented. It is an overapproximation, because we only add the implemented label if someone tells us to. So it is hard to tell, but looking at the list (especially the second page with the older proposals), for a few of them I can’t remember seeing a MR on GHC. But of course that’s just an impression. Do you see value in deliberating over proposals without an indication that someone actually plans to try to implement them? Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From mail at joachim-breitner.de Wed Aug 24 10:41:44 2022 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 24 Aug 2022 12:41:44 +0200 Subject: [ghc-steering-committee] Please review #517: Require implementors before proposal submission, Shepherd: Simon PJ In-Reply-To: References: <010f01826e0021e3-55dae02e-af8c-4f09-93c8-d2cf4c5c0cf6-000000@us-east-2.amazonses.com> <478fe508de4fe7eb2f3c9cd6a5a30a21deed1772.camel@joachim-breitner.de> <010f0182b76f35dd-6cb751ee-faf3-4af5-8119-6e66ef1ef576-000000@us-east-2.amazonses.com> Message-ID: <34ef99ce7f5c28f3564efbfe45ca88042ee264d0.camel@joachim-breitner.de> Hi, Am Dienstag, dem 23.08.2022 um 14:01 -0400 schrieb Eric Seidel: > Perhaps rather than requiring an implementor to volunteer, we should > lean more on groups like the Haskell Foundation to *fund the > implementation of proposals*? isn’t that the same thing? If the Haskell Foundation (or someone else) says “we’ll fund all accepted proposal”, then my proposed requirement would be vacuously satisfied. Personally, though, I prefer if this committee does not also have to worry about resource allocation for the HF… Nor do I think that the HF should fund “random good ideas” – there will always be more good ideas than resources to implement them. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From iavor.diatchki at gmail.com Wed Aug 24 10:48:29 2022 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Wed, 24 Aug 2022 13:48:29 +0300 Subject: [ghc-steering-committee] Please review #517: Require implementors before proposal submission, Shepherd: Simon PJ In-Reply-To: <3a087b34044bd520f319450590cb7627b01d36ae.camel@joachim-breitner.de> References: <0A370D47-CEE0-471F-BB8E-5B9B1CA440DF@gmail.com> <3a087b34044bd520f319450590cb7627b01d36ae.camel@joachim-breitner.de> Message-ID: Hello, FYI, Ross Paterson has started an implementation of "#106 Define Kinds Without Promotion". His branch is here: https://gitlab.haskell.org/RossPaterson/ghc/-/tree/wip/type-data I am also planning to help, but have been busy with work and life stuff, so haven't had a chance to contribute yet. Cheers, -Iavor On Wed, Aug 24, 2022 at 1:37 PM Joachim Breitner wrote: > Hi, > > Am Mittwoch, dem 24.08.2022 um 11:49 +0300 schrieb Vladislav Zavialov > (int-index): > > I am uncertain. Do we have any case studies? What are examples of > > proposals that were submitted without an implementor? > > The list at > > https://github.com/ghc-proposals/ghc-proposals/pulls?page=2&q=is%3Apr+label%3A%22Accepted%22+-label%3A%22Implemented%22 > lists PRs marked as accepted but not implemented. It is an > overapproximation, because we only add the implemented label if someone > tells us to. So it is hard to tell, but looking at the list (especially > the second page with the older proposals), for a few of them I can’t > remember seeing a MR on GHC. But of course that’s just an impression. > > Do you see value in deliberating over proposals without an indication > that someone actually plans to try to implement them? > > Cheers, > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Wed Aug 24 10:49:45 2022 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 24 Aug 2022 12:49:45 +0200 Subject: [ghc-steering-committee] Proposal #270: Support pun-free code. Recommendation: accept In-Reply-To: References: Message-ID: Hi, thanks for the summary. Am Mittwoch, dem 24.08.2022 um 07:27 +0100 schrieb Chris Dornan: > To (avoiding) this end, I suggest that we include wording in the > user guide section documenting this extension to the effect that > there is no consensus on the desirability or otherwise of the punful > code the extension seeks to address. I wonder if it isn’t really on us to address that and try to establish a consensus about where we want Haskell to evolve to? Should we not try to provide unifying guidance by choosing between puns are fine and good practice, the language evolution takes that into account and puns are discouraged and undesirable, as they do not work smoothly with the Haskell we envision for the future, we provide work-arounds (like this proposal) when dealing with code that still has them It seems that by accepting https://github.com/ghc-proposals/ghc-proposals/pull/378 we went down the second road, although the wording in that proposal, in section https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0378-dependent-type-design.rst#non-design-of-dependent-types is much more diplomatic than I was above. Maybe the sentiment could be that puns are a bit like lazy IO: It used to be the thing to do so, it will continue to work, but they should no longer be considered current good practice. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From simon.peytonjones at gmail.com Wed Aug 24 10:57:04 2022 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Wed, 24 Aug 2022 11:57:04 +0100 Subject: [ghc-steering-committee] Proposal #522: Or patterns. Recommendation: accept In-Reply-To: <010f0182b7fd3756-e5122221-8aa8-42ee-a12e-1841ac772f83-000000@us-east-2.amazonses.com> References: <010f0182b7fd3756-e5122221-8aa8-42ee-a12e-1841ac772f83-000000@us-east-2.amazonses.com> Message-ID: I'm mildly in favour of acceptance. One more thing. But a reasonably easy thing. Simon On Fri, 19 Aug 2022 at 22:23, Richard Eisenberg wrote: > Hi all, > > I have been assigned to shepherd Proposal #522, Or patterns. > > Proposal text: > https://github.com/knothed/ghc-proposals/blob/master/proposals/0522-or-patterns.rst > Proposal discussion: > https://github.com/ghc-proposals/ghc-proposals/pull/522 > > The proposal introduces a syntax for or-patterns. Here is an example: > > case ... of > K1 a b c -> Just ... > K2 d e -> Just ... > (K3 {} ; K4 {} ; K5 {}) -> Nothing > > *Summary* > > Without this proposal, the author of the above code would have to either > use a _ pattern for the last line, meaning that future new constructors > added to the datatype would go unreported by compiler warnings, or to write > the K3, K4, and K5 cases separately, repeating the right-hand side. > Or-patterns are common in other languages. > > The authors include a nice section ( > https://github.com/knothed/ghc-proposals/blob/master/proposals/0522-or-patterns.rst#id12) > on alternative syntax. I recommend reading it; it made me feel better about > the proposed semi-colon syntax. > > The proposal requires that each pattern in an or-pattern must not bind any > variables. Any provided contexts (e.g. GADT equalities) and existential > variables are ignored, and any required context is combined across the > disjuncts in the pattern. > > Two implementors are named in the proposal. > > *Recommendation* > > I recommend acceptance. This proposal is relatively simple, will lead to a > nice quality-of-life improvement, is future-compatible (*) with or-patterns > that *do* bind variables/contexts/existentials, and has a natural reading > to users unfamiliar with the extension. > > (*): I suppose that the fact that an or-pattern discards equalities might > mean that a later improvement that retains these equalities might interfere > with type inference (because in-scope equalities cause type variables to > become untouchable). But I will choose not to worry about this. > > The downsides are: > - Yet another feature to think about, including a new extension name. > - Yet another feature to implement and maintain. > > I think the improvements to the language are worth these downsides, though > I could be convinced otherwise. > > Please let me know what you think about this proposal. I'm hoping to > accept this proposal in three weeks (a bit longer than my usual timeframe, > due to it being a popular time for holidays), unless there is objection. > > Thanks! > Richard > _______________________________________________ > 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 Aug 24 11:46:03 2022 From: chris at chrisdornan.com (Chris Dornan) Date: Wed, 24 Aug 2022 12:46:03 +0100 Subject: [ghc-steering-committee] Proposal #270: Support pun-free code. Recommendation: accept In-Reply-To: References: Message-ID: I don’t think we should be in the business of overturning by fiat significant conventions that have been long established. I am really quite concerned about people pointing to proposals accepted by a technical committee and expanding this into wide-ranging normative conventions to be imposed on the general Haskell community after the fact. Accordingly I am flipping my recommendation. I now agree with Simon. Until we are satisfied that the wider consensus has been established — that these puns are no longer good style — I think we should *not* accept this proposal. The risks are too great and, as Simon points out, the potential benefits are not compelling. Chris > On 2022-08-24, at 11:49, Joachim Breitner wrote: > > Hi, > > thanks for the summary. > > Am Mittwoch, dem 24.08.2022 um 07:27 +0100 schrieb Chris Dornan: >> To (avoiding) this end, I suggest that we include wording in the >> user guide section documenting this extension to the effect that >> there is no consensus on the desirability or otherwise of the punful >> code the extension seeks to address. > > I wonder if it isn’t really on us to address that and try to establish > a consensus about where we want Haskell to evolve to? Should we not try > to provide unifying guidance by choosing between > > puns are fine and good practice, the language evolution takes that into > account > > and > > puns are discouraged and undesirable, as they do not work smoothly with > the Haskell we envision for the future, > we provide work-arounds (like this proposal) when dealing with code > that still has them > > It seems that by accepting > https://github.com/ghc-proposals/ghc-proposals/pull/378 we went down > the second road, although the wording in that proposal, in section > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0378-dependent-type-design.rst#non-design-of-dependent-types > is much more diplomatic than I was above. > > Maybe the sentiment could be that puns are a bit like lazy IO: It used > to be the thing to do so, it will continue to work, but they should no > longer be considered current good practice. > > Cheers, > 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 chris at chrisdornan.com Wed Aug 24 11:49:37 2022 From: chris at chrisdornan.com (Chris Dornan) Date: Wed, 24 Aug 2022 12:49:37 +0100 Subject: [ghc-steering-committee] Proposal #522: Or patterns. Recommendation: accept In-Reply-To: References: <010f0182b7fd3756-e5122221-8aa8-42ee-a12e-1841ac772f83-000000@us-east-2.amazonses.com> Message-ID: Count me in — yes to Or patterns for me. > On 2022-08-24, at 11:57, Simon Peyton Jones wrote: > > I'm mildly in favour of acceptance. One more thing. But a reasonably easy thing. > > Simon > > On Fri, 19 Aug 2022 at 22:23, Richard Eisenberg wrote: > Hi all, > > I have been assigned to shepherd Proposal #522, Or patterns. > > Proposal text: https://github.com/knothed/ghc-proposals/blob/master/proposals/0522-or-patterns.rst > Proposal discussion: https://github.com/ghc-proposals/ghc-proposals/pull/522 > > The proposal introduces a syntax for or-patterns. Here is an example: > > case ... of > K1 a b c -> Just ... > K2 d e -> Just ... > (K3 {} ; K4 {} ; K5 {}) -> Nothing > > Summary > > Without this proposal, the author of the above code would have to either use a _ pattern for the last line, meaning that future new constructors added to the datatype would go unreported by compiler warnings, or to write the K3, K4, and K5 cases separately, repeating the right-hand side. Or-patterns are common in other languages. > > The authors include a nice section (https://github.com/knothed/ghc-proposals/blob/master/proposals/0522-or-patterns.rst#id12) on alternative syntax. I recommend reading it; it made me feel better about the proposed semi-colon syntax. > > The proposal requires that each pattern in an or-pattern must not bind any variables. Any provided contexts (e.g. GADT equalities) and existential variables are ignored, and any required context is combined across the disjuncts in the pattern. > > Two implementors are named in the proposal. > > Recommendation > > I recommend acceptance. This proposal is relatively simple, will lead to a nice quality-of-life improvement, is future-compatible (*) with or-patterns that do bind variables/contexts/existentials, and has a natural reading to users unfamiliar with the extension. > > (*): I suppose that the fact that an or-pattern discards equalities might mean that a later improvement that retains these equalities might interfere with type inference (because in-scope equalities cause type variables to become untouchable). But I will choose not to worry about this. > > The downsides are: > - Yet another feature to think about, including a new extension name. > - Yet another feature to implement and maintain. > > I think the improvements to the language are worth these downsides, though I could be convinced otherwise. > > Please let me know what you think about this proposal. I'm hoping to accept this proposal in three weeks (a bit longer than my usual timeframe, due to it being a popular time for holidays), unless there is objection. > > Thanks! > Richard > _______________________________________________ > 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 From eric at seidel.io Wed Aug 24 11:58:22 2022 From: eric at seidel.io (Eric Seidel) Date: Wed, 24 Aug 2022 07:58:22 -0400 Subject: [ghc-steering-committee] Please review #517: Require implementors before proposal submission, Shepherd: Simon PJ In-Reply-To: <34ef99ce7f5c28f3564efbfe45ca88042ee264d0.camel@joachim-breitner.de> References: <34ef99ce7f5c28f3564efbfe45ca88042ee264d0.camel@joachim-breitner.de> Message-ID: It is similar, but I think my framing puts the pebble in the right shoe. Consider it from this perspective, when we accept a proposal we are *committing* GHC to accept a patch implementing it (assuming it passes code review etc). I think there’s also a general expectation that GHC *will* implement all accepted proposals in a timely manner. That’s why we’re having the present discussion. The question is whose responsibility is it to ensure implementation? In principle it should be GHC’s responsibility, but GHC is largely a volunteer-driven project and it’s not fair to expect a bunch of unpaid labor from the GHC devs. But the Haskell community at large has an interest in a fully-featured GHC. And the Haskell Foundation represents these interests and has funding to realize them. So what I’m suggesting is that we could partner with the Foundation to establish a bounty or grant program to implement proposals that do not already have a committed implementer. Sent from my iPhone > On Aug 24, 2022, at 06:42, Joachim Breitner wrote: > > Hi, > >> Am Dienstag, dem 23.08.2022 um 14:01 -0400 schrieb Eric Seidel: >> Perhaps rather than requiring an implementor to volunteer, we should >> lean more on groups like the Haskell Foundation to *fund the >> implementation of proposals*? > > isn’t that the same thing? If the Haskell Foundation (or someone else) > says “we’ll fund all accepted proposal”, then my proposed requirement > would be vacuously satisfied. > > Personally, though, I prefer if this committee does not also have to > worry about resource allocation for the HF… > > Nor do I think that the HF should fund “random good ideas” – there will > always be more good ideas than resources to implement them. > > Cheers, > 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 simon.peytonjones at gmail.com Wed Aug 24 22:09:09 2022 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Wed, 24 Aug 2022 23:09:09 +0100 Subject: [ghc-steering-committee] Please review #517: Require implementors before proposal submission, Shepherd: Simon PJ In-Reply-To: References: <34ef99ce7f5c28f3564efbfe45ca88042ee264d0.camel@joachim-breitner.de> Message-ID: > > Consider it from this perspective, when we accept a proposal we are > *committing* GHC to accept a patch implementing it (assuming it passes code > review etc). I think there’s also a general expectation that GHC *will* > implement all accepted proposals in a timely manner. > I don't think so! We have always said that accepting a proposal places *no* obligation on the GHC team to implement it. I think the point of this proposal is to make it a bit clearer that it is the author's responsibility to corral resources (from volunteers, from the HF, from a company) to implement their proposal. That said, I think it should be fine for an author to create a PR and initiate discussion on a proposal way before they have an implementor. It's just that when they want to submit to the committee (which *does* have an obligation to review and decide, a process that has costs), at that point they should line up an plausible implementor so that we don't spend time reviewing proposals that are unlikely to get implemented. But a proposal could get to an advanced stage without that final step. Simon Simon On Wed, 24 Aug 2022 at 12:58, Eric Seidel wrote: > It is similar, but I think my framing puts the pebble in the right shoe. > > Consider it from this perspective, when we accept a proposal we are > *committing* GHC to accept a patch implementing it (assuming it passes code > review etc). I think there’s also a general expectation that GHC *will* > implement all accepted proposals in a timely manner. That’s why we’re > having the present discussion. > > The question is whose responsibility is it to ensure implementation? In > principle it should be GHC’s responsibility, but GHC is largely a > volunteer-driven project and it’s not fair to expect a bunch of unpaid > labor from the GHC devs. > > But the Haskell community at large has an interest in a fully-featured > GHC. And the Haskell Foundation represents these interests and has funding > to realize them. So what I’m suggesting is that we could partner with the > Foundation to establish a bounty or grant program to implement proposals > that do not already have a committed implementer. > > Sent from my iPhone > > > On Aug 24, 2022, at 06:42, Joachim Breitner > wrote: > > > > Hi, > > > >> Am Dienstag, dem 23.08.2022 um 14:01 -0400 schrieb Eric Seidel: > >> Perhaps rather than requiring an implementor to volunteer, we should > >> lean more on groups like the Haskell Foundation to *fund the > >> implementation of proposals*? > > > > isn’t that the same thing? If the Haskell Foundation (or someone else) > > says “we’ll fund all accepted proposal”, then my proposed requirement > > would be vacuously satisfied. > > > > Personally, though, I prefer if this committee does not also have to > > worry about resource allocation for the HF… > > > > Nor do I think that the HF should fund “random good ideas” – there will > > always be more good ideas than resources to implement them. > > > > Cheers, > > 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 eric at seidel.io Thu Aug 25 01:19:15 2022 From: eric at seidel.io (Eric Seidel) Date: Wed, 24 Aug 2022 21:19:15 -0400 Subject: [ghc-steering-committee] Please review #517: Require implementors before proposal submission, Shepherd: Simon PJ In-Reply-To: References: <34ef99ce7f5c28f3564efbfe45ca88042ee264d0.camel@joachim-breitner.de> Message-ID: <94b02ae1-43cc-4836-b710-e22be42d5d30@www.fastmail.com> On Wed, Aug 24, 2022, at 18:09, Simon Peyton Jones wrote: >> Consider it from this perspective, when we accept a proposal we are *committing* GHC to accept a patch implementing it (assuming it passes code review etc). I think there’s also a general expectation that GHC *will* implement all accepted proposals in a timely manner. > > I don't think so! We have always said that accepting a proposal > places *no* obligation on the GHC team to implement it. Sorry, I didn't mean that the GHC team would implement the proposal themselves. The expectation, I think, is that *someone* will implement the proposal, and that GHC will accept the patch. > I think the point of this proposal is to make it a bit clearer that it > is the author's responsibility to corral resources (from volunteers, > from the HF, from a company) to implement their proposal. This is where I don't know if I agree. The author already invested considerable effort writing and revising the proposal itself. And we gave our seal of approval that the proposal is a worthwhile addition to GHC. I think this is where an *institution* should step in and ensure that, for the good of the whole ecosystem, accepted proposals are implemented in a timely manner. Maybe what this looks like in practice is that proposals without committed implementers are "conditionally accepted" or something, and then the author can separately petition the HF to fund the implementation. That's effectively what you're suggesting, but if we do that there should be an established process that authors can follow, and an agreement from e.g. the HF that they would consider funding such work. We should set the precedent first, and then require authors to follow it. From baldurpet at gmail.com Thu Aug 25 11:17:09 2022 From: baldurpet at gmail.com (=?UTF-8?Q?Baldur_Bl=C3=B6ndal?=) Date: Thu, 25 Aug 2022 11:17:09 +0000 Subject: [ghc-steering-committee] Please review #517: Require implementors before proposal submission, Shepherd: Simon PJ In-Reply-To: References: Message-ID: I agree with the sentiment that it is better to have a proposal that is actually going to be implemented rather than just debated. It gives a sense of seriousness to accepted GHC proposals. Acceptance should be understood to mean it will eventually become part of GHC, and I think people already understand it that way. What I don't want is for this to deter anyone from suggesting ideas and improvements; Simon's third bullet point assuaged my fear of that. New ideas can be freely debated, and people can choose to focus on proposals with an implementation plan. I suppose an author of a proposal can also take on the responsibility to rally support for an implementation if they are otherwise unable to produce one. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Sun Aug 28 14:40:11 2022 From: marlowsd at gmail.com (Simon Marlow) Date: Sun, 28 Aug 2022 15:40:11 +0100 Subject: [ghc-steering-committee] Please review #500: Add implicit import proposal, New Shepherd: Simon M. In-Reply-To: <5ef21ee8fbe9a215b87efcb56cec578a22399200.camel@joachim-breitner.de> References: <035c69c81b6fe9921600c053e2ee919b62e1837a.camel@joachim-breitner.de> <5ef21ee8fbe9a215b87efcb56cec578a22399200.camel@joachim-breitner.de> Message-ID: Apologies for the delay here, holidays and then a large backlog... As a reminder, this proposal would let you use qualified names like Data.Trace.trace without adding an explicit import. I've reviewed the whole comment section of the proposal, but I'm finding it difficult to arrive at a clear recommendation. Some points: - There's a certain amount of convenience enabled by the extension, for sure. And other languages (OCaml, Rust) have a similar feature. But - There are compile-time performance implications that are as-yet unmeasured. I've asked for more data on this in the github thread. - A strong argument against (in my opinion) is that tooling could do this automatically, rendering this extension redundant. HLS doesn't currently insert imports for qualified names automatically, but couldn't it? Other language servers do this kind of thing (e.g. Python) - The behaviour with respect to instances is a little too implicit. Removing a qualified identifier might eliminate an implicit import and thus hide some instances, causing the compiler to reject the module. I'm personally leaning towards rejection, but I don't feel strongly enough to actually recommend that. What do others think? Cheers Simon On Mon, 1 Aug 2022 at 07:45, Joachim Breitner wrote: > Dear Committee, > > Add implicit import proposal > has been submitted by Tristan de Cacqueray > > This is an interesting one: At first glance it looks quite un- > haskellish, but it’s hard to poing out what’s, if anything, is wrong > with it. I expect that the discussion will revolve not so much about > technical issues, but more about best practices and our vision for > Haskell’s look and feel. > > https://github.com/ghc-proposals/ghc-proposals/pull/500 > > https://github.com/TristanCacqueray/ghc-proposals/blob/implicit-import/proposals/0000-implicit-import.rst > > I originally assigned this to Baldur in May, but we haven't heard from > you. To be considerate of the proposal author’s motivation, I’d like to > re-assign this to Simon Marlow. > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Mon Aug 29 15:19:48 2022 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 29 Aug 2022 17:19:48 +0200 Subject: [ghc-steering-committee] Please review #500: Add implicit import proposal, New Shepherd: Simon M. In-Reply-To: References: <035c69c81b6fe9921600c053e2ee919b62e1837a.camel@joachim-breitner.de> <5ef21ee8fbe9a215b87efcb56cec578a22399200.camel@joachim-breitner.de> Message-ID: <44fdf8fa0e53a0704339da2086f40353ee07cc87.camel@joachim-breitner.de> Hi Simon, thanks for picking this up. I am similarly torn. Everytime I have to add and then remove Debug.Trace from my import list I am annoyed. And especially for quick scripts etc. having less red tape to go through seems to be an improvement. So I see the benefit. If I’d be creating a programming language afresh, I might be inclined to allow that – a qualified identifier is already quite explicit, after all! (I admit that I still don’t use the latest tooling available, maybe someone using LSP for all their Haskell uses might have a different.) On the other hand, this is not a fresh programming language, we have lived okish without this so far, and in particular the behavior with regard to instances might be sufficient reasons to reject this – although not without some regret. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From eric at seidel.io Mon Aug 29 16:59:29 2022 From: eric at seidel.io (Eric Seidel) Date: Mon, 29 Aug 2022 12:59:29 -0400 Subject: [ghc-steering-committee] Please review #500: Add implicit import proposal, New Shepherd: Simon M. In-Reply-To: <44fdf8fa0e53a0704339da2086f40353ee07cc87.camel@joachim-breitner.de> References: <035c69c81b6fe9921600c053e2ee919b62e1837a.camel@joachim-breitner.de> <5ef21ee8fbe9a215b87efcb56cec578a22399200.camel@joachim-breitner.de> <44fdf8fa0e53a0704339da2086f40353ee07cc87.camel@joachim-breitner.de> Message-ID: <5eea0371-7de1-4a4d-92d9-870e73768683@www.fastmail.com> If the main benefit we expect from this feature is improved development productivity (from not having to jump around to insert temporary imports), I can think of two ways to restrict the feature to keep most of the benefit without dealing with tricky questions like instance imports. 1a. Never import instances via an implicit import. This limits the usefulness somewhat if you're trying to use an overloaded method, because you might depend on the instances that would come alongside the method. But, it's an easy rule to remember, and our goal is to improve dev productivity, not provide a production-grade solution. 1b. Always import instances via an implicit import. Same argument as above, but perhaps more friendly to productivity. 2. Always warn about implicit imports so they mostly stay out of production builds. On Mon, Aug 29, 2022, at 11:19, Joachim Breitner wrote: > Hi Simon, > > thanks for picking this up. > > I am similarly torn. > > Everytime I have to add and then remove Debug.Trace from my import list > I am annoyed. And especially for quick scripts etc. having less red > tape to go through seems to be an improvement. So I see the benefit. If > I’d be creating a programming language afresh, I might be inclined to > allow that – a qualified identifier is already quite explicit, after > all! > (I admit that I still don’t use the latest tooling available, maybe > someone using LSP for all their Haskell uses might have a different.) > > On the other hand, this is not a fresh programming language, we have > lived okish without this so far, and in particular the behavior with > regard to instances might be sufficient reasons to reject this – > although not without some regret. > > > Cheers, > 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 mail at joachim-breitner.de Tue Aug 30 06:30:32 2022 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 30 Aug 2022 08:30:32 +0200 Subject: [ghc-steering-committee] GHC Proposals session at Haskell Symposium at ICFP Message-ID: <5c154197c2caf99456552c05a84c83ac7cd7a2e5.camel@joachim-breitner.de> 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 at joachim-breitner.de http://www.joachim-breitner.de/ From iavor.diatchki at gmail.com Wed Aug 31 05:23:49 2022 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Wed, 31 Aug 2022 08:23:49 +0300 Subject: [ghc-steering-committee] Please review #500: Add implicit import proposal, New Shepherd: Simon M. In-Reply-To: <5eea0371-7de1-4a4d-92d9-870e73768683@www.fastmail.com> References: <035c69c81b6fe9921600c053e2ee919b62e1837a.camel@joachim-breitner.de> <5ef21ee8fbe9a215b87efcb56cec578a22399200.camel@joachim-breitner.de> <44fdf8fa0e53a0704339da2086f40353ee07cc87.camel@joachim-breitner.de> <5eea0371-7de1-4a4d-92d9-870e73768683@www.fastmail.com> Message-ID: Hello, I am not on the committee anymore but I like reading the discussions while having a coffee, so I thought I'd chime in with my 2c: using an `import` declaration, you get to introduce a shorter qualifier (the `as` clause), which for me as a programmer is essential---I don't remember the last time I used a `qualified` import without an `as`, which is what you'd get with this proposal. -Iavor On Mon, Aug 29, 2022, 20:00 Eric Seidel wrote: > If the main benefit we expect from this feature is improved development > productivity (from not having to jump around to insert temporary imports), > I can think of two ways to restrict the feature to keep most of the benefit > without dealing with tricky questions like instance imports. > > 1a. Never import instances via an implicit import. This limits the > usefulness somewhat if you're trying to use an overloaded method, because > you might depend on the instances that would come alongside the method. > But, it's an easy rule to remember, and our goal is to improve dev > productivity, not provide a production-grade solution. > > 1b. Always import instances via an implicit import. Same argument as > above, but perhaps more friendly to productivity. > > 2. Always warn about implicit imports so they mostly stay out of > production builds. > > On Mon, Aug 29, 2022, at 11:19, Joachim Breitner wrote: > > Hi Simon, > > > > thanks for picking this up. > > > > I am similarly torn. > > > > Everytime I have to add and then remove Debug.Trace from my import list > > I am annoyed. And especially for quick scripts etc. having less red > > tape to go through seems to be an improvement. So I see the benefit. If > > I’d be creating a programming language afresh, I might be inclined to > > allow that – a qualified identifier is already quite explicit, after > > all! > > (I admit that I still don’t use the latest tooling available, maybe > > someone using LSP for all their Haskell uses might have a different.) > > > > On the other hand, this is not a fresh programming language, we have > > lived okish without this so far, and in particular the behavior with > > regard to instances might be sufficient reasons to reject this – > > although not without some regret. > > > > > > Cheers, > > 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 marlowsd at gmail.com Wed Aug 31 19:07:18 2022 From: marlowsd at gmail.com (Simon Marlow) Date: Wed, 31 Aug 2022 20:07:18 +0100 Subject: [ghc-steering-committee] Please review #500: Add implicit import proposal, New Shepherd: Simon M. In-Reply-To: <5eea0371-7de1-4a4d-92d9-870e73768683@www.fastmail.com> References: <035c69c81b6fe9921600c053e2ee919b62e1837a.camel@joachim-breitner.de> <5ef21ee8fbe9a215b87efcb56cec578a22399200.camel@joachim-breitner.de> <44fdf8fa0e53a0704339da2086f40353ee07cc87.camel@joachim-breitner.de> <5eea0371-7de1-4a4d-92d9-870e73768683@www.fastmail.com> Message-ID: I just checked the proposal and in fact, Eric's 1a option below is what is being proposed. That is, implicit imports don't bring any new instances into scope. For me I don't think that actually simplifies things though. Because now, we have a difference in semantics between using an implicit import and an explicit import, and a weird corner case that will surprise people. I'm somewhat attracted by option 2, warning about implicit imports. If this is supposed to be a convenience feature during development, I could see that being useful. In a similar vein, I suggested on github that implicit imports could work only for modules outside the current package, which avoids a lot of the implementation complexity because we don't have to extract implicit imports to perform dependency analysis. As a language feature I think that's a terrible design, but as a productivity tool during development it makes some sense - rather like the intention behind the existing hacky feature in GHCi that the whole proposal is inspired by. But do we actually want that kind of feature? I'm still not sure really. Cheers Simon On Mon, 29 Aug 2022 at 18:00, Eric Seidel wrote: > If the main benefit we expect from this feature is improved development > productivity (from not having to jump around to insert temporary imports), > I can think of two ways to restrict the feature to keep most of the benefit > without dealing with tricky questions like instance imports. > > 1a. Never import instances via an implicit import. This limits the > usefulness somewhat if you're trying to use an overloaded method, because > you might depend on the instances that would come alongside the method. > But, it's an easy rule to remember, and our goal is to improve dev > productivity, not provide a production-grade solution. > > 1b. Always import instances via an implicit import. Same argument as > above, but perhaps more friendly to productivity. > > 2. Always warn about implicit imports so they mostly stay out of > production builds. > > On Mon, Aug 29, 2022, at 11:19, Joachim Breitner wrote: > > Hi Simon, > > > > thanks for picking this up. > > > > I am similarly torn. > > > > Everytime I have to add and then remove Debug.Trace from my import list > > I am annoyed. And especially for quick scripts etc. having less red > > tape to go through seems to be an improvement. So I see the benefit. If > > I’d be creating a programming language afresh, I might be inclined to > > allow that – a qualified identifier is already quite explicit, after > > all! > > (I admit that I still don’t use the latest tooling available, maybe > > someone using LSP for all their Haskell uses might have a different.) > > > > On the other hand, this is not a fresh programming language, we have > > lived okish without this so far, and in particular the behavior with > > regard to instances might be sufficient reasons to reject this – > > although not without some regret. > > > > > > Cheers, > > 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 marlowsd at gmail.com Wed Aug 31 19:13:31 2022 From: marlowsd at gmail.com (Simon Marlow) Date: Wed, 31 Aug 2022 20:13:31 +0100 Subject: [ghc-steering-committee] Please review #500: Add implicit import proposal, New Shepherd: Simon M. In-Reply-To: References: <035c69c81b6fe9921600c053e2ee919b62e1837a.camel@joachim-breitner.de> <5ef21ee8fbe9a215b87efcb56cec578a22399200.camel@joachim-breitner.de> <44fdf8fa0e53a0704339da2086f40353ee07cc87.camel@joachim-breitner.de> <5eea0371-7de1-4a4d-92d9-870e73768683@www.fastmail.com> Message-ID: Anyway, for what it's worth the proposer has asked to mark the proposal dormant until the compile-time performance issues can be resolved. Thanks everyone for the discussion, we can revisit this if/when the proposal wakes up again. Cheers Simon On Wed, 31 Aug 2022 at 20:07, Simon Marlow wrote: > I just checked the proposal and in fact, Eric's 1a option below is what is > being proposed. That is, implicit imports don't bring any new instances > into scope. > > For me I don't think that actually simplifies things though. Because now, > we have a difference in semantics between using an implicit import and an > explicit import, and a weird corner case that will surprise people. > > I'm somewhat attracted by option 2, warning about implicit imports. If > this is supposed to be a convenience feature during development, I could > see that being useful. In a similar vein, I suggested on github that > implicit imports could work only for modules outside the current package, > which avoids a lot of the implementation complexity because we don't have > to extract implicit imports to perform dependency analysis. As a language > feature I think that's a terrible design, but as a productivity tool during > development it makes some sense - rather like the intention behind the > existing hacky feature in GHCi that the whole proposal is inspired by. > But do we actually want that kind of feature? I'm still not sure really. > > Cheers > Simon > > On Mon, 29 Aug 2022 at 18:00, Eric Seidel wrote: > >> If the main benefit we expect from this feature is improved development >> productivity (from not having to jump around to insert temporary imports), >> I can think of two ways to restrict the feature to keep most of the benefit >> without dealing with tricky questions like instance imports. >> >> 1a. Never import instances via an implicit import. This limits the >> usefulness somewhat if you're trying to use an overloaded method, because >> you might depend on the instances that would come alongside the method. >> But, it's an easy rule to remember, and our goal is to improve dev >> productivity, not provide a production-grade solution. >> >> 1b. Always import instances via an implicit import. Same argument as >> above, but perhaps more friendly to productivity. >> >> 2. Always warn about implicit imports so they mostly stay out of >> production builds. >> >> On Mon, Aug 29, 2022, at 11:19, Joachim Breitner wrote: >> > Hi Simon, >> > >> > thanks for picking this up. >> > >> > I am similarly torn. >> > >> > Everytime I have to add and then remove Debug.Trace from my import list >> > I am annoyed. And especially for quick scripts etc. having less red >> > tape to go through seems to be an improvement. So I see the benefit. If >> > I’d be creating a programming language afresh, I might be inclined to >> > allow that – a qualified identifier is already quite explicit, after >> > all! >> > (I admit that I still don’t use the latest tooling available, maybe >> > someone using LSP for all their Haskell uses might have a different.) >> > >> > On the other hand, this is not a fresh programming language, we have >> > lived okish without this so far, and in particular the behavior with >> > regard to instances might be sufficient reasons to reject this – >> > although not without some regret. >> > >> > >> > Cheers, >> > 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 lists at richarde.dev Wed Aug 31 22:00:15 2022 From: lists at richarde.dev (Richard Eisenberg) Date: Wed, 31 Aug 2022 22:00:15 +0000 Subject: [ghc-steering-committee] Please review #500: Add implicit import proposal, New Shepherd: Simon M. In-Reply-To: References: <035c69c81b6fe9921600c053e2ee919b62e1837a.camel@joachim-breitner.de> <5ef21ee8fbe9a215b87efcb56cec578a22399200.camel@joachim-breitner.de> <44fdf8fa0e53a0704339da2086f40353ee07cc87.camel@joachim-breitner.de> <5eea0371-7de1-4a4d-92d9-870e73768683@www.fastmail.com> Message-ID: <010f0182f5eb4fd1-f3e2f9b0-6f6c-4c1b-abbb-e0782a6367ff-000000@us-east-2.amazonses.com> Just because it's paged in now: I, too, am on the fence. But I want to vote against warning at every implicit import, because I often develop with -Werror on. If the whole point of this is to enable Debug.Trace.trace, then I've lost the benefit. I'm attracted by the idea of leaning more heavily on external tooling. For example, we can imagine a command-line option that specifies an `import` statement. Tooling can generate the right such options. That would seem to be better than making this a language feature, because an external tool is in a better position to know e.g. how to disambiguate if there are multiple X.Y modules available from different packages. Richard > On Aug 31, 2022, at 3:13 PM, Simon Marlow wrote: > > Anyway, for what it's worth the proposer has asked to mark the proposal dormant until the compile-time performance issues can be resolved. > > Thanks everyone for the discussion, we can revisit this if/when the proposal wakes up again. > > Cheers > Simon > > On Wed, 31 Aug 2022 at 20:07, Simon Marlow > wrote: > I just checked the proposal and in fact, Eric's 1a option below is what is being proposed. That is, implicit imports don't bring any new instances into scope. > > For me I don't think that actually simplifies things though. Because now, we have a difference in semantics between using an implicit import and an explicit import, and a weird corner case that will surprise people. > > I'm somewhat attracted by option 2, warning about implicit imports. If this is supposed to be a convenience feature during development, I could see that being useful. In a similar vein, I suggested on github that implicit imports could work only for modules outside the current package, which avoids a lot of the implementation complexity because we don't have to extract implicit imports to perform dependency analysis. As a language feature I think that's a terrible design, but as a productivity tool during development it makes some sense - rather like the intention behind the existing hacky feature in GHCi that the whole proposal is inspired by. But do we actually want that kind of feature? I'm still not sure really. > > Cheers > Simon > > On Mon, 29 Aug 2022 at 18:00, Eric Seidel > wrote: > If the main benefit we expect from this feature is improved development productivity (from not having to jump around to insert temporary imports), I can think of two ways to restrict the feature to keep most of the benefit without dealing with tricky questions like instance imports. > > 1a. Never import instances via an implicit import. This limits the usefulness somewhat if you're trying to use an overloaded method, because you might depend on the instances that would come alongside the method. But, it's an easy rule to remember, and our goal is to improve dev productivity, not provide a production-grade solution. > > 1b. Always import instances via an implicit import. Same argument as above, but perhaps more friendly to productivity. > > 2. Always warn about implicit imports so they mostly stay out of production builds. > > On Mon, Aug 29, 2022, at 11:19, Joachim Breitner wrote: > > Hi Simon, > > > > thanks for picking this up. > > > > I am similarly torn. > > > > Everytime I have to add and then remove Debug.Trace from my import list > > I am annoyed. And especially for quick scripts etc. having less red > > tape to go through seems to be an improvement. So I see the benefit. If > > I’d be creating a programming language afresh, I might be inclined to > > allow that – a qualified identifier is already quite explicit, after > > all! > > (I admit that I still don’t use the latest tooling available, maybe > > someone using LSP for all their Haskell uses might have a different.) > > > > On the other hand, this is not a fresh programming language, we have > > lived okish without this so far, and in particular the behavior with > > regard to instances might be sufficient reasons to reject this – > > although not without some regret. > > > > > > Cheers, > > 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 > _______________________________________________ > 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: