Proposal process status

Yuras Shumovich shumovichy at
Thu Jul 21 12:51:01 UTC 2016

On Wed, 2016-07-20 at 18:37 +0200, Ben Gamari wrote:
> Yuras Shumovich <shumovichy at> 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

> 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

More information about the ghc-devs mailing list