Re: Proposal process status

On Wed, 2016-07-20 at 18:37 +0200, Ben Gamari wrote:

Yuras Shumovich writes:

...

Looks like reddit is a wrong place, so I'm replicating my comment here:

Thanks for your comments Yuras!

...

...

  * Do you feel the proposed process is an improvement over the status quo?

Yes, definitely. The existing process is too vague, so formalizing it is a win in any case.

Good to hear.

...

...

  * What would you like to see changed in the proposed process, if     anything?

The proposed process overlaps with the Language Committee powers. In theory the Committee works on language standard, but de facto Haskell is GHC/Haskell and GHC/Haskell is Haskell. Adding new extension to GHC adds new extension to Haskell. So I'd like the process to enforce separation between experimental extensions (not recommended in production code) and language improvements. I'd like the process to specify how the GHC Committee is going to communicate and share powers with the Language Committee.

To clarify I think Language Committee here refers to the Haskell Prime committee, right?

Yes, Herbert used "Haskell Prime 2020 committee" and "Haskell Language committee" interchangeable in the original announcement https://mail.ha skell.org/pipermail/haskell-prime/2016-April/004050.html

I think these two bodies really do serve different purposes. Historically the Haskell Prime committee has been quite conservative in the sorts of changes that they standardized; as far as I know almost all of them come from a compiler. I would imagine that the GHC Committee would be a gate-keeper for proposals entering GHC and only some time later, when the semantics and utility of the extension are well-understood, would the Haskell Prime committee consider introducing it to the Report. As far as I understand it, this is historically how things have worked in the past, and I don't think this new process would change that.

I think it is what the process should change. It makes sense to have two committees only if we have multiple language implementations, but it is not the case. Prime committee may accept or reject e.g. GADTs, but it will change nothing because people will continue using GADTs regardless, and any feature accepted by the Prime committee will necessary be compatible with GADTs extension. The difference between standard and GHC-specific extensions is just a question of formal specification, interesting mostly for language lawyer. (But it is good to have such formal specification even for GHC- specific extensions, right?) Probably it is time to return -fglasgow-exts back to separate standard feature from experimental GHC-specific ones.

Of course, let me know if I'm off-base here.

Cheers,

- Ben