[ghc-steering-committee] Please review #517: Require implementors before proposal submission, Shepherd: Simon PJ

[Eric Seidel]

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 <lists at richarde.dev> wrote:
>> 
>> 
>>> On Aug 19, 2022, at 4:44 AM, Joachim Breitner <mail at joachim-breitner.de> 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