Proposal process status

[Yuras Shumovich]

On Thu, 2016-07-21 at 13:25 -0400, Richard Eisenberg wrote:
> > 
> > On Jul 21, 2016, at 11:29 AM, Yuras Shumovich <shumovichy at gmail.com
> > > wrote:
> > 
> > Unfortunately Haskell *is* implementation-defined language. You
> > can't
> > compile any nontrivial package from Hackage using Haskell2010 GHC.
> 
> Sadly, I agree with this statement. And I think this is what we're
> trying to change.

And I'd like it to be changed too. I'm paid for writing SW in Haskell,
and I want to have a standard. At the same time I'm (probably unusual)
Haskell fan, so I want new cool features. Don't you see a conflict of
interests?
https://www.reddit.com/r/haskell/comments/4oyxo2/blog_contributing_to_ghc/d4iaz5t

> 
> > And
> > the same will be true for Haskell2020. We rely on GHC-specific
> > extensions everywhere, directly or indirectly. If the goal of the
> > Haskell Prime is to change that, then the GHC-specific extensions
> > should not be first class citizens in the ecosystem.
> 
> My hope is that Haskell2020 will allow us to differentiate between
> standardized extensions and implementation-defined ones. A key part
> of this hope is that we'll get enough extensions in the first set to
> allow a sizeable portion of our ecosystem to used only standardized
> extensions.

It is hopeless. Haskell2020 will not include TemplateHaskell, GADTs,
etc. Haskell Prime committee will never catch up if GHC will continue
adding new extensions. In 2020 everybody will use pattern synonyms,
overloaded record fields and TypeInType, so the standard will be as far
from practice as it is now.

The whole idea of language extensions, as it is right now, works
against Haskell Prime.
https://www.reddit.com/r/haskell/comments/46jq4i/what_is_the_eventual_fate_of_all_of_these_ghc/d05q9no

I abandoned my CStructures proposal because of that. I don't want to
increase entropy.
https://phabricator.haskell.org/D252

> > 
> > We can continue pretending that Haskell is standard-defined
> > language,
> > but it will not help to change the situation. 
> 
> But writing a new standard that encompasses prevalent usage will help
> to change the situation. And that's the process I'm hoping to
> contribute to.

I see only one real way to change the situation -- standardize all
widely used extensions and declare anything new as experimental unless
accepted by the Haskell Prime Committee. Probably there are other ways,
but we need to cleanup the mess ASAP. New extensions only contribute to
the mess -- that is my point.

> 
> Richard