I think the most important thing is to be able to point to a designated point where discussions must take place. This means if anything comes up elsewhere it can be routed there to be "official". Alan On Wed, Jul 20, 2016 at 1:42 PM, Yuras Shumovich wrote:

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

On Wed, 2016-07-20 at 11:36 +0200, Ben Gamari wrote:

...

Hello everyone,

As you hopefully know, a few weeks ago we proposed a new process [1] for collecting, discussing, and deciding upon changes to GHC and its Haskell superset. While we have been happy to see a small contingent of contributors join the discussion, the number is significantly smaller than the set who took part in the earlier Reddit discussions.

In light of this, we are left a bit uncertain of how to proceed. So, we would like to ask you to let us know your feelings regarding the proposed process:

* 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.

...

* Why? (this needn't be long, just a sentence hitting the major points)

* 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.

Thanks, Yuras.

...

That's all. Again, feel free to reply either on the GitHub pull request [1] or this thread if you would prefer. Your response needn't be long; we just want to get a sense of how much of the community feels that 1) this effort is worth undertaking, and 2) that the proposal before us is in fact an improvement over the current state of affairs.

Thanks for your help!

Cheers,

- Ben

[1] https://github.com/ghc-proposals/ghc-proposals/pull/1 _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-user s

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

On Wednesday, July 20, 2016, Ben Gamari wrote:

Yuras Shumovich javascript:;> 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?

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.

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

As one of the 20 members of the Haskell (Prime) 2020 committee id like to interject on this front: the preliminary discussions the committee has had thus far had a clear agreement that we shall aim to be a bit more progressive about what shall be included in the standard. The main bar will be the extent to which features or capabilities can be articulated without over specifying implementation details and can tractably have compatible but different compilers for the standard. I think some of the other prime committee members can articulate this a bit better than I, so don't hold me to this precise phrasing ;)

Cheers,

- Ben

On July 21, 2016 at 8:51:15 AM, Yuras Shumovich (shumovichy@gmail.com) wrote:

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.

I disagree. By the stated goals of the H2020 Committee, if it is successful, then by 2020 it will still for the most part have only standardized ony a _portion_ of the extentions that now exist today. There’s always been a barrier between implementation and standard in the Haskell language, that’s precisely one of the things that _keeps_ it from having become entirely implementation-defined despite the prevelance of extensions. Having two entirely different processes here (though obviously not without communication between the individuals involved) helps maintain that. —Gershom

On Thu, 2016-07-21 at 10:32 -0400, Gershom B wrote:

On July 21, 2016 at 8:51:15 AM, Yuras Shumovich (shumovichy@gmail.com ) wrote:

...

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.

I disagree. By the stated goals of the H2020 Committee, if it is successful, then by 2020 it will still for the most part have only standardized ony a _portion_ of the extentions that now exist today.

Yes, I know. But don't you see how narrow the responsibility of the H2020 Committee is? GHC Committee makes all important decisions, and H2020 just collects some of GHC extensions into a set of "standard" ones. It is useful only when "nonstandard" extensions are not widely used (e.g. marked as experimental, and are not recommended for day-to- day use).

There’s always been a barrier between implementation and standard in the Haskell language, that’s precisely one of the things that _keeps_ it from having become entirely implementation-defined despite the prevelance of extensions.

Unfortunately Haskell *is* implementation-defined language. You can't compile any nontrivial package from Hackage using Haskell2010 GHC. 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. Otherwise there is no sense in two committees. We can continue pretending that Haskell is standard-defined language, but it will not help to change the situation. 

Having two entirely different processes here (though obviously not without communication between the individuals involved) helps maintain that.

—Gershom

On Thu, 2016-07-21 at 13:25 -0400, Richard Eisenberg wrote:

...

On Jul 21, 2016, at 11:29 AM, Yuras Shumovich

...

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/d4...

...

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_o... 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

On 07/21/2016 08:38 PM, Richard Eisenberg wrote:

...

On Jul 21, 2016, at 2:25 PM, Yuras Shumovich wrote:

[--snip--]

...

Haskell Prime committee will never catch up if GHC will continue adding new extensions.

Of course not. But I believe some libraries also refrain from using new extensions for precisely the same reason -- that the new extensions have yet to fully gel.

Indeed, a major issue right now is that Haskell-as-practiced is *sooo* far from Haskell-as-standardized (H2010) that it's basically hopeless to implement most non-trivial things using only H2010. We're not even talking missing very advanced things, just "basic" things like MPTCs, ScopedTypeVariables not being the standard behavior, various derivations, auto-Typeable, TypeFams vs. FunDeps[1], plus various minor syntactic conveniences[2], BangPatterns, etc. etc. Just FTR: Of course, I realize that standardizing any of this is *much* easier said than done, so this is NOT meant as a slight against anyone! Regards, [1] Alright, this one might be a little more contentious, but the basic functionality of FunDeps (or the equivalent functionality form TypeFams) is sometimes necessary. [2] These I can and will work around if necessary, but as long as something else in my package requires anything non-Haskell2010, why should I bother?

+1 from me for keeping the two separate as well. While GHC may be the obviously prevalent Haskell compiler it is a far from the only one, And I’d hate to have to look at a proposal for adding an extension to GHC (which would be riddled with GHC specific implementation specifics) Rather than a clean specification. Maybe I’m naïve but I also see the Haskell committees as doing more than just copy pasting what’s worked. But also evaluate how it can be done Better. I can perfectly well see situations where the implementation in GHC ended up being less useful than It should be just because of Implementation quirks/difficulties in GHC. Cheers, Tamar From: Richard Eisenberg

Iavor Diatchki writes:

Hello Ben,

I posted this when you originally asked for feed-back, but perhaps it got buried among the rest of the e-mails.

Indeed it seems that way. Sorry about that!

I think the proposal sounds fairly reasonable, but it is hard to say how well it will work in practice until we try it, and we should be ready to change it if needs be.

Right. I fully expect that we will have to iterate on it.

Some clarifying questions on the intended process: 1. After submitting the initial merge request, is the person making the proposal to wait for any kind of acknowledgment, or just move on to step 2?

The discussion phase can happen asynchronously from any action by the Committee. Of course, the Committee should engauge in discussion early, but I don't think any sort of acknowledgement is needed. An open pull request should be taken to mean "let's discuss this idea."

2. Is the discussion going to happen on one of the mailing lists, if so which? Is it the job of the proposing person to involve/notify the committee about the discussion? If so, how are they to find out who is on the committee?

The proposed process places the discussion in a pull request. The idea here is to use well-understood and widely-used code review tools to faciliate the conversation. The Committee members will be notified of the open pull request by the usual event notification mechanism (e.g. in GitHub one can subscribe to a repository).

3. How does one actually perform step 3, another pull request or simply an e-mail to someone?

The opening of the pull request would mark the beginning of the discussion period. When the author feels that the discussion has come to something of a conclusion, they will request that the GHC Committee consider the proposal for acceptable by leaving a comment on the pull request.

Typo: two separate bullets in the proposal are labelled as 4.

I believe this should be fixed now. Thanks! Cheers, - Ben