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

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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

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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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.

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

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

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Hi, also in light of the discussion at Haskell Symposium, can we proceed with this (or drop this)? Arnaud was most vocally in the “against” camp; are you still against it? NB: Opening PRs and discussing them with the general public is welcome even before implementors have been found, and committee members can of course join that discussion. Only the formal committee submission would be blocked until implementors have been found. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Hello, while I think the problem exists and would welcome a process refinement, it certainly isn’t so big to spend too much of our own attention on it (which is the precise resource I was trying to save). And it certainly isn’t pressing enough to hold a vote when there isn’t consensus. So given that we don’t have a consensus, I suggest to not spend more time on it, let’s reject it (and remember where it is to be revived, if and when the problem becomes more clearer visible). Cheers, Joachim (with no pride dented, no worries) Am Dienstag, dem 20.09.2022 um 15:09 +0200 schrieb Spiwack, Arnaud:

I haven't been convinced yet. As I said in my previous email, I'm a priori against this proposal. But this is a gut feeling. More importantly than that, I don't feel that we have documented how other communities handle this. I also don't feel that the number of unimplemented proposals is so high as to be a problem.

On Mon, Sep 19, 2022 at 7:42 PM Joachim Breitner wrote:

...

Hi,

also in light of the discussion at Haskell Symposium, can we proceed with this (or drop this)? Arnaud was most vocally in the “against” camp; are you still against it?

NB: Opening PRs and discussing them with the general public is welcome even before implementors have been found, and committee members can of course join that discussion. Only the formal committee submission would be blocked until implementors have been found.

Cheers, Joachim

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

As you say, it's not that big a deal. I'm content to reject for now. I'm sure we'll keep coming back to it! Simon On Sun, 2 Oct 2022 at 13:03, Joachim Breitner wrote:

Hi,

Am Dienstag, dem 20.09.2022 um 15:43 +0200 schrieb Joachim Breitner:

...

So given that we don’t have a consensus, I suggest to not spend more time on it, let’s reject it (and remember where it is to be revived, if and when the problem becomes more clearer visible).

no complaints about this either? I’ll mark it as rejected in a few days unless someone shouts.

Cheers, Joachim

-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

This all unfolded while I was laid flat by covid, but I would vote in favor of this proposal. I've seen sufficient evidence of folks unhappy with accepted-but-not-implemented proposals (most recently Matt Parsons about the modifiers proposal) that I think this would be an improvement. That said, I think we should have broader support before accepting a proposal such as this. Richard

On Oct 3, 2022, at 4:28 AM, Spiwack, Arnaud wrote:

If we do come back to it, it's going to be stronger evidence that something in that space is needed.

On Mon, Oct 3, 2022 at 10:26 AM Simon Peyton Jones mailto:simon.peytonjones@gmail.com> wrote: As you say, it's not that big a deal. I'm content to reject for now. I'm sure we'll keep coming back to it!

Simon

On Sun, 2 Oct 2022 at 13:03, Joachim Breitner mailto:mail@joachim-breitner.de> wrote: Hi,

Am Dienstag, dem 20.09.2022 um 15:43 +0200 schrieb Joachim Breitner:

...

So given that we don’t have a consensus, I suggest to not spend more time on it, let’s reject it (and remember where it is to be revived, if and when the problem becomes more clearer visible).

no complaints about this either? I’ll mark it as rejected in a few days unless someone shouts.

Cheers, Joachim

-- Joachim Breitner mail@joachim-breitner.de mailto:mail@joachim-breitner.de http://www.joachim-breitner.de/ http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee