On 2018-10-05 09:10 AM, Henrik Nilsson wrote:

Hi,

On 10/05/2018 01:20 PM, Mario Blažević wrote:

...

     I hereby propose we formally disband the present Haskell 2020 committee. Our performance has been so dismal

It has.

And I should apologise in particular: I've just had far less time than I thought over the past year for a variety of reasons.

...

that I feel this is the only course of action that gives Haskell 2020 any chance of fruition. A new committee could then be formed with some more dedicated membership.

I'm less convinced about that, though. I believe those who signed up for H2020 actually are people who believe in the value of an updated standard and has core expertise to make it happen.

    Regarding the beliefs, if we really represent the most zealous group of Haskell enthusiasts, I have to say the community is in deep trouble. I have no evidence, but I can only hope you're wrong.     As for the expertise, my impression is that *everybody* who self-nominated for the committee got accepted. My own self-nomination e-mail [1] explicitly said that

The main reason I'm applying is because I'm afraid that the commitee might disband like the previous one. If there are enough members already, feel free to ignore my nomination.

Yet I'm in. This was not a high bar to clear.

I can't see how giving up and forming a new group would speed things up or even increase the chance of success.

    I was kinda hoping for a Simon ex machina, where a few universally-accepted members of the community hand-pick a new committee. Alternatively, we could come up with some stricter criteria for the next committee before we disband but that assumes we can even get a quorum.     Lest I'm suspected of some Machiavellian plot, let me be clear that I refuse to be a part of the next committee, if my proposal should be accepted. Honestly I feel that all members of the present committee with any sense of shame should recuse themselves as well, but that's not up to me.

Instead, what about focusing on identifying a couple of things that absolutely would have to be in H2020 to make a new standard worthwhile, like multi-parameter type classes, possibly GADTs, then figure out what else is needed to support that (like what Anthony Clayden sketched), and with that as a basis, find out exactly what technical problems, if any, are hindering progress?

If this could be neatly summarized, then we'd actually be in a position to make some progress.

    That is much the plan we agreed on over a year ago during ICFP 2018. The activity since then is plain to see. [1] http://mail.haskell.org/pipermail/haskell-prime/2015-September/003939.html

agreed... i think theres still room for the current for the current committee to succeed (though depending on ambitions it should maybe slide into being 2022 standard perhaps?) I cant speak for other members, but i'm still hopeful about putting together some of the language improvements to the standard in time for 2020, life and other commitments (in addition to living) permitting. I do think that its ultimately a social / communal activity, and humans are best motivated when thats in the clear. So the more progress some folks make, the more motivated one way or another other folks will be! On Fri, Oct 5, 2018 at 1:05 PM Simon Peyton Jones via Haskell-prime < haskell-prime@haskell.org> wrote:

I think the difficulty has always been in finding enough people who are

* Well-informed and well-qualified * Willing to spend the time to standardise language features

GHC does not help the situation: it's a de-facto standard, which reduces the incentives to spend time in standardisation.

I don’t think we should blame anyone for not wanting to invest this time -- no shame here. It is a very significant commitment, as I know from editing the Haskell 98 report and the incentives are weak. Because of that, I am not very optimistic about finding such a group -- we have been abortively trying for several years.

If we want to change that, the first thing is to build a case that greater standardisation is not just an "abstract good" that we all subscribe to, but something whose lack is holding us back.

Simon

| -----Original Message----- | From: Haskell-prime On Behalf Of | Mario Blaževic | Sent: 05 October 2018 17:47 | To: haskell-prime@haskell.org | Subject: Re: Quo vadis? | | On 2018-10-05 09:10 AM, Henrik Nilsson wrote: | > Hi, | > | > On 10/05/2018 01:20 PM, Mario Blažević wrote: | >> I hereby propose we formally disband the present Haskell 2020 | >> committee. Our performance has been so dismal | > | > It has. | > | > And I should apologise in particular: I've just had far less time than | > I thought over the past year for a variety of reasons. | > | >> that I feel this is the | >> only course of action that gives Haskell 2020 any chance of fruition. | >> A new committee could then be formed with some more dedicated | membership. | > | > I'm less convinced about that, though. I believe those who signed up | > for H2020 actually are people who believe in the value of an updated | > standard and has core expertise to make it happen. | | Regarding the beliefs, if we really represent the most zealous group | of Haskell enthusiasts, I have to say the community is in deep trouble. I | have no evidence, but I can only hope you're wrong. | | As for the expertise, my impression is that *everybody* who self- | nominated for the committee got accepted. My own self-nomination e-mail | [1] explicitly said that | | | > The main reason I'm applying is because I'm afraid that the commitee | > might disband like the previous one. If there are enough members | > already, feel free to ignore my nomination. | | Yet I'm in. This was not a high bar to clear. | | | > I can't see how giving up and forming a new group would speed things | > up or even increase the chance of success. | | I was kinda hoping for a Simon ex machina, where a few universally- | accepted members of the community hand-pick a new committee. | Alternatively, we could come up with some stricter criteria for the next | committee before we disband but that assumes we can even get a quorum. | | Lest I'm suspected of some Machiavellian plot, let me be clear that | I refuse to be a part of the next committee, if my proposal should be | accepted. Honestly I feel that all members of the present committee with | any sense of shame should recuse themselves as well, but that's not up to | me. | | | > Instead, what about focusing on identifying a couple of things that | > absolutely would have to be in H2020 to make a new standard | > worthwhile, like multi-parameter type classes, possibly GADTs, then | > figure out what else is needed to support that (like what Anthony | > Clayden sketched), and with that as a basis, find out exactly what | > technical problems, if any, are hindering progress? | > | > If this could be neatly summarized, then we'd actually be in a | > position to make some progress. | | That is much the plan we agreed on over a year ago during ICFP 2018. | The activity since then is plain to see. | | | [1] | http://mail.haskell.org/pipermail/haskell-prime/2015- | September/003939.html | | _______________________________________________ | Haskell-prime mailing list | Haskell-prime@haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

On 08/10/2018 02:51, Mario Blažević wrote:

Neither an abstract good nor a good abstraction are something Haskell has ever shied away from. I don't know if you're actually asking for a list of "concrete goods"? To start with, every GHC extension that's added to a standard means:

- one less item to type in the ubiquitous {-# LANGUAGE ScaryExtension #-} pragma, - one less item to understand for beginners, - one less item whose necessity must be justified to the team, and - one less item of whose future stability the management needs to be convinced.

I suspect we need to follow the lead of other languages here and accept that the LANGUAGE pragma is actually a necessity and a positive good for engineering in the presence of changing language versions. That would mean we should support more standardised pragmas in the vein of the existing ones in the report, and perhaps that GHC should give more information about the stability of extensions. Perhaps when an extension was first introduced and the GHC versions in which the last two changes more significant than "bug fix" happened? There might even be a need for versioning of extensions. I'd be remiss if I didn't suggest a candidate with a specific problem, a specific goal and a possible solution to its problem. So, a modest proposal: - Standardise OverloadedStrings as an available-but-disabled feature - Allow default statements for the IsString class without OverloadedStrings, using that type for all string literals - At some future stage, we can use this to migrate away from [Char] as the default string literal type - The Haskell2010 pragma and its successors can be used to ensure code written to standard doesn't suffer bit rot when migration happens

On 09/10/2018 00:58, Mario Blažević wrote:

On 2018-10-07 11:32 PM, Philippa Cowderoy wrote:

...

I'd be remiss if I didn't suggest a candidate with a specific problem, a specific goal and a possible solution to its problem. So, a modest proposal:

- Standardise OverloadedStrings as an available-but-disabled feature - Allow default statements for the IsString class without OverloadedStrings, using that type for all string literals - At some future stage, we can use this to migrate away from [Char] as the default string literal type - The Haskell2010 pragma and its successors can be used to ensure code written to standard doesn't suffer bit rot when migration happens

The second bullet point could use some clarification. Would you mind commenting on the existing defaulting proposal at https://github.com/haskell/rfcs/pull/18 ?

I've been away from the overall process and I'm not in best health right now, so it'll take a while to catch up but I'll do my best. The gist (which someone else may have covered) is that it's not overloading if you have exactly one type of string literals, even if we let the user say which type it is. I've read enough to see I'll have to have my thinking cap on while writing much more than that as a useful comment though, not least because of the interaction with an imported defaults mechanism that normally needs to work with a sequence of defaults.

Mario: as a non-committee member but interested observer, if you yourself wanted to proceed to put the report in the repo, what obstacles would stand in your way, and could we clear them out so you could take charge of that task? Cheers, Gershom On October 7, 2018 at 9:52:14 PM, Mario Blažević (blamario@ciktel.net) wrote: On 2018-10-05 01:05 PM, Simon Peyton Jones wrote:

I think the difficulty has always been in finding enough people who are

* Well-informed and well-qualified * Willing to spend the time to standardise language features

GHC does not help the situation: it's a de-facto standard, which reduces the incentives to spend time in standardisation.

I don’t think we should blame anyone for not wanting to invest this time -- no shame here. It is a very significant commitment, as I know from editing the Haskell 98 report and the incentives are weak. Because of that, I am not very optimistic about finding such a group -- we have been abortively trying for several years.

That sounds like we're stuck with the committee we have. In that case, Simon, could you at least pull some strings to have the actual Haskell Report placed in the same repository? This is a basic precondition if we expect individual efforts to accomplish anything. The minimal steps to actually updating the Haskell Report are: 1. write an RFC (we have some already), 2. have it provisionally accepted (not entirely clear how - would    "no negative votes in 4 weeks" count?), 3. add the modification to the Haskell Report to the RFC, 4. receive the final approval, 5. merge the RFC into the report. Steps #3 and #5 depend on having the report in the same repository with the RFCs. This has been agreed over a year ago: https://mail.haskell.org/pipermail/haskell-prime/2017-September/004319.html https://mail.haskell.org/pipermail/haskell-prime/2017-October/thread.html https://mail.haskell.org/pipermail/haskell-prime/2017-November/thread.html https://mail.haskell.org/pipermail/haskell-prime/2018-March/004356.html

If we want to change that, the first thing is to build a case that greater standardisation is not just an "abstract good" that we all subscribe to, but something whose lack is holding us back.

Neither an abstract good nor a good abstraction are something Haskell has ever shied away from. I don't know if you're actually asking for a list of "concrete goods"? To start with, every GHC extension that's added to a standard means: - one less item to type in the ubiquitous {-# LANGUAGE ScaryExtension #-} pragma, - one less item to understand for beginners, - one less item whose necessity must be justified to the team, and - one less item of whose future stability the management needs to be convinced. I could go on. _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

| That sounds like we're stuck with the committee we have. In that case, | Simon, could you at least pull some strings to have the actual Haskell | Report placed in the same repository? Sounds like a good plan. If the haskell-prime committee agreed to do this, and it's only a matter of doing it, then you just need someone with commit rights to the relevant repository. I don't know who that is (it certainly isn't me), but if you make them a PR, and ping them by email, it would be easy for them to execute. Simon | -----Original Message----- | From: Mario Blažević | Sent: 08 October 2018 02:52 | To: Simon Peyton Jones ; haskell-prime@haskell.org | Subject: Re: Quo vadis? | | On 2018-10-05 01:05 PM, Simon Peyton Jones wrote: | > I think the difficulty has always been in finding enough people who | > are | > | > * Well-informed and well-qualified | > * Willing to spend the time to standardise language features | > | > GHC does not help the situation: it's a de-facto standard, which | reduces the incentives to spend time in standardisation. | > | > I don’t think we should blame anyone for not wanting to invest this | time -- no shame here. It is a very significant commitment, as I know | from editing the Haskell 98 report and the incentives are weak. Because | of that, I am not very optimistic about finding such a group -- we have | been abortively trying for several years. | | | That sounds like we're stuck with the committee we have. In that case, | Simon, could you at least pull some strings to have the actual Haskell | Report placed in the same repository? This is a basic precondition if we | expect individual efforts to accomplish anything. The minimal steps to | actually updating the Haskell Report are: | | 1. write an RFC (we have some already), | 2. have it provisionally accepted (not entirely clear how - would |    "no negative votes in 4 weeks" count?), 3. add the modification to | the Haskell Report to the RFC, 4. receive the final approval, 5. merge | the RFC into the report. | | Steps #3 and #5 depend on having the report in the same repository with | the RFCs. This has been agreed over a year ago: | | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has | kell.org%2Fpipermail%2Fhaskell-prime%2F2017- | September%2F004319.html&data=02%7C01%7Csimonpj%40microsoft.com%7C227f | 843099c5489509da08d62cc0a25f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7 | C636745603204766102&sdata=z3meiZAXQoKzsiOzPAjicdzLbL2vRp0NPgIsUFM2h%2 | FY%3D&reserved=0 | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has | kell.org%2Fpipermail%2Fhaskell-prime%2F2017- | October%2Fthread.html&data=02%7C01%7Csimonpj%40microsoft.com%7C227f84 | 3099c5489509da08d62cc0a25f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6 | 36745603204766102&sdata=ilw5EXJyblsVyqs3e7iczbTpG3TexjNY7nmSokMJFvM%3 | D&reserved=0 | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has | kell.org%2Fpipermail%2Fhaskell-prime%2F2017- | November%2Fthread.html&data=02%7C01%7Csimonpj%40microsoft.com%7C227f8 | 43099c5489509da08d62cc0a25f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C | 636745603204766102&sdata=T5zS7b9Swyn%2FWPW8Yqt9XTOf38KSqYmMkgzglesjAR | Y%3D&reserved=0 | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has | kell.org%2Fpipermail%2Fhaskell-prime%2F2018- | March%2F004356.html&data=02%7C01%7Csimonpj%40microsoft.com%7C227f8430 | 99c5489509da08d62cc0a25f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636 | 745603204766102&sdata=bSimqVnSL0Yp18LhYMJ9LsqnPWT4QmT%2BKpyRwAISbdY%3 | D&reserved=0 | | | > If we want to change that, the first thing is to build a case that | greater standardisation is not just an "abstract good" that we all | subscribe to, but something whose lack is holding us back. | | Neither an abstract good nor a good abstraction are something Haskell has | ever shied away from. I don't know if you're actually asking for a list | of "concrete goods"? To start with, every GHC extension that's added to a | standard means: | | - one less item to type in the ubiquitous {-# LANGUAGE ScaryExtension #-} | pragma, | - one less item to understand for beginners, | - one less item whose necessity must be justified to the team, and | - one less item of whose future stability the management needs to be | convinced. | | I could go on.