I'd like to vehemently agree with Henrik here. :) Personally, I think AMP was the right thing to do, but I don't think FTP was the right thing. And I don't think changes that break code are necessarily bad either, just some of them. (To clarify, I'm against the Foldable class, but not Traversable. It would have been quite feasible to have the latter, but not the former.) -- Lennart -----Original Message----- From: Haskell-prime [mailto:haskell-prime-bounces@haskell.org] On Behalf Of Henrik Nilsson Sent: 21 October 2015 11:17 To: haskell-prime@haskell.org List; Haskell Libraries Subject: Re: Breaking Changes and Long Term Support Haskell Hi all, Jeremy wrote:

There seems to be a fair amount of friction between those who want to > introduce new features or fix significant historical warts in the base > libraries - even if this requires breaking changes - and those who > insist on no significant breaking changes in new releases, regardless > of the reason or how much warning was given.

With respect, and without commenting on the merits of the proposal that is then outlined (Long-Term Support Haskell), I don't think this is an accurate description of the two main positions in the debate at all. Most of those who have argued against MRP, for example, have made it very clear that they are not at all against any breaking change. But they oppose breaking changes to Haskell itself, including central libraries, as defined by the Haskell report, unless the benefits are very compelling indeed. Speaking for myself, I have had to clarify this position a number of times now, as there has been a tendency by the some proponents of the proposed changes to suggest that those who disagree are against all changes, the long term implication being that Haskell would "stagnate and die". And in the light of the above, I felt compelled to clarify this position again. It's not about no more changes ever. It is about ensuring that changes are truly worthwhile and have wide support. Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham nhn@cs.nott.ac.uk This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at http://www.standardchartered.com/en/incorporation-details.html Insofar as this communication contains any market commentary, the market commentary has been prepared by sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied for any other purpose, and is subject to the relevant disclaimers available at http://wholesalebanking.standardchartered.com/en/utility/Pages/d-mkt.aspx Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign on the term sheet to acknowledge in respect of the same. Please visit http://wholesalebanking.standardchartered.com/en/capabilities/financialmarke... for important information with respect to derivative products.

On 10/21/2015 07:30 AM, Simon Peyton Jones wrote:

Friends

I think it's good for us to debate the question of how we should balance innovation against change; and how we should make those decisions in future. Geoff's message had some good ideas, especially this bit:

| Proposal 2: After a suitable period of discussion on the libraries list, the | Core Libraries Committee will summarize the arguments for and against a | proposal and post it, along with a (justified) preliminary decision, to a | low-traffic, announce-only email list. After another suitable period of | discussion, they will issue a final decision. What is a suitable period of | time? Perhaps that depends on the properties of the proposal, such as | whether it breaks backwards compatibility.

Identifying major changes to the libraries, and having a better publicised, more RFC-like process for deliberating them, would be a good thing. I believe that the Core Libraries committee is thinking actively about this.

| Personally, I think AMP was the right thing to do, but I don't think FTP was | the right thing.

These make good examples to motivate future changes to our process. But in the end FTP was subject to a pretty broad deliberative process, precisely along the lines that Geoff suggests above. We had two clearly-articulated alternatives, a discrete call for opinions broadcast to every Haskell channel we could find, a decent interval for people to respond, and (as it turned out) a very clear preponderance of opinion in one direction. In a big community, even a broad consultation may yield a result that some think is ill-advised. That's part of the joyful burden of being a big community.

Let's look forward, not back. I think we can do better in future than we have done in the past. I don't think we can hope for unanimity, but I think we can reasonably seek

* transparency; * clarity about what decisions are on the table; * broad consultation about decisions that affect a broad constituency; and * a decent opportunity to debate them without having to be involved in massive email threads. Let's try do to that.

Simon

PS: For what it's worth I'm less keen on Geoff's other proposal:

| Proposal 3: A decision regarding any proposal that significantly affects | backwards compatibility is within the purview of the Haskell Prime | Committee, not the Core Libraries Committee.

*Precisely* the same issues will arise whether it's CLC or HPC. And the HPC is going to be jolly busy with language issues. Moving the question from one group to another risks avoiding the issue rather than addressing it.

For the record, I am also not sure Proposal 3 is a good idea :) However, I do think we could clarify what the respective responsibilities of the core libraries committee and Haskell Prime committees are. One possible choice is that the core libraries committee is responsible for changes to the core libraries that do not affect libraries in the report. It is meant to be nimble, able to quickly deal with the large volume of library changes that do not impact backwards compatibility. In this scenario, the Haskell Prime committee, using a longer deliberative process, would consider the more impactful library changes and batch them up into new reports. You are absolutely correct that moving the question to the Haskell Prime committee risks pushing the issue around. The idea behind the separation outlined above is to reduce the treadmill; the two bodies use different processes, with different time frames, to arrive at decisions. Some library decisions may deserve a longer deliberative process. Cheers, Geoff

Well said! I do have a small worry that the longer roll out window will be harder to manage given that every thing is done by (outstanding) volunteers. But maybe the answer there is that ghc should do major version releases more frequently :), eg every 9 months instead of every 12! 😀 On Wednesday, October 21, 2015, Dan Doel wrote:

Hello,

I'm Dan Doel. I'm on the core libraries committee (though I'm speaking only for myself). As I recall, one of the reasons I got tapped for it was due to my having some historical knowledge about Haskell; not because I was there, but because I've gone back and looked at some old reports and whatnot (and sometimes think they're better than what we have now).

But, I was around (of course) when the core libraries committee started up, so perhaps I can play the role of historian for this as well.

The reason the committee exists is because a couple years ago, people brought up the ideas that were finally realized in the Applicative-Monad proposal and the Foldable-Traversable proposal. A lot of people weighed in saying they thought they were a good idea, and significantly fewer people weighed in saying they thought that it shouldn't happen for various reasons---roughly the same things that people are still bringing up about these proposals.

This wasn't the first time that happened, either. I think it was widely agreed among most users that Functor should be a superclass of Monad since I started learning Haskell around 10 years ago. And once Applicative was introduced, it was agreed that that should go in the middle of the two. But it appeared that it would never happen, despite a significant majority thinking it should, because no one wanted to do anything without pretty much unanimous consent.

So, one question that got raised is: why should this majority of people even use Haskell/GHC anymore? Why shouldn't they start using some other language that will let them change 15-year-old mistakes, or adapt to ideas that weren't even available at that time (but are still fairly old and established, all things considered). And the answer was that there should be some body empowered to decide to move forward with these ideas, even if there is some dissent. And frankly, it wasn't going to be the prime committee, because it hadn't shown any activity in something like 3 years at the time, and even when it was active, it didn't make anywhere near the sort of changes that were being discussed.

And the kicker to me is, many things that people are complaining about again (e.g. the FTP) were the very things that the committee was established to execute. I don't think we had a formal vote on that proposal, because we didn't need to. Our existence was in part to execute that proposal (and AMP). And then a year ago, when it was finally time to release the changes, there was another ruckus. And we still didn't have a CLC vote on the matter. What we did was conduct a community poll, and then SPJ reviewed the submissions. But I don't mean to pass the buck to him, because I'm pretty sure he was worried that we were crazy, and overstepping our bounds. Just, the results of the survey were sufficient for him to not overrule us.

So my point is this: there seems to be some sentiment that the core libraries committee is unsound, and making bad decisions. But the complaints are mostly not even about actual decisions we made (aside from maybe Lennart Augustsson's, where he is unhappy with details of the FTP that you can blame on us, but were designed to break the least code, instead of being the most elegant; if we had pleased him more, we would have pleased others less). They are about the reasons for founding the committee in the first place. You can blame us, if you like, because I think it's certain that we would have approved them if we had formally voted. We just didn't even need to do so.

Forgive me if I'm wrong, but suggestions that these decisions should have been deferred to a Haskell Prime committee mean, to me, that the hope is that they would have been rejected. That the Haskell Prime committee should have just vetoed these proposals that something like 80% or more of practicing Haskell users (as far as we can tell) wanted for years before they finally happened. That the Haskell Prime committee should be responsible for enforcing the very status quo that led to the CLC in the first place, where proposals with broad support but minority dissent never pass for various core modules.

If this is the case, then one could simply repose the earlier question: why should most of these people stick around to obey by the Haskell Prime committee's pronouncements, instead of getting to work on a language that incorporates their input?

And if it isn't, then I don't ultimately understand what the complaints are. We try to accomplish the (large) changes in a manner that allows transition via refactoring over multiple versions (and as I mentioned earlier, some complaints are that we compromised _too much_ for this). And in light of the more recent complaints, it's even been decided that our time frames should be longer. Rolling up changes into a report just seems like it makes transitions less smooth. Unless the idea is to make GHC capable of switching out entire base library sets; but someone has to implement that, and once you have it, it makes the report specifications _less_ essential.

Anyhow, that's my history lesson. Take it as you (all) will.

Cheers, -- Dan

...

On 10/21/2015 07:30 AM, Simon Peyton Jones wrote:

...

Friends

I think it's good for us to debate the question of how we should balance innovation against change; and how we should make those decisions in future. Geoff's message had some good ideas, especially this bit:

| Proposal 2: After a suitable period of discussion on the libraries

...

...

| Core Libraries Committee will summarize the arguments for and against a | proposal and post it, along with a (justified) preliminary decision, to a | low-traffic, announce-only email list. After another suitable period of | discussion, they will issue a final decision. What is a suitable

...

...

| time? Perhaps that depends on the properties of the proposal, such as | whether it breaks backwards compatibility.

Identifying major changes to the libraries, and having a better

...

...

| Personally, I think AMP was the right thing to do, but I don't think

FTP was

...

| the right thing.

These make good examples to motivate future changes to our process. But in the end FTP was subject to a pretty broad deliberative process,

...

...

Let's look forward, not back. I think we can do better in future than

we have done in the past. I don't think we can hope for unanimity, but I

...

...

* transparency; * clarity about what decisions are on the table; * broad consultation about decisions that affect a broad constituency; and * a decent opportunity to debate them without having to be involved in massive email threads. Let's try do to that.

Simon

PS: For what it's worth I'm less keen on Geoff's other proposal:

| Proposal 3: A decision regarding any proposal that significantly

affects

...

| backwards compatibility is within the purview of the Haskell Prime | Committee, not the Core Libraries Committee.

*Precisely* the same issues will arise whether it's CLC or HPC. And

On Wed, Oct 21, 2015 at 10:43 AM, Geoffrey Mainland javascript:;> wrote: list, the period of publicised, more RFC-like process for deliberating them, would be a good thing. I believe that the Core Libraries committee is thinking actively about this. precisely along the lines that Geoff suggests above. We had two clearly-articulated alternatives, a discrete call for opinions broadcast to every Haskell channel we could find, a decent interval for people to respond, and (as it turned out) a very clear preponderance of opinion in one direction. In a big community, even a broad consultation may yield a result that some think is ill-advised. That's part of the joyful burden of being a big community. think we can reasonably seek the HPC is going to be jolly busy with language issues. Moving the question from one group to another risks avoiding the issue rather than addressing it.

...

For the record, I am also not sure Proposal 3 is a good idea :)

However, I do think we could clarify what the respective responsibilities of the core libraries committee and Haskell Prime committees are.

One possible choice is that the core libraries committee is responsible for changes to the core libraries that do not affect libraries in the report. It is meant to be nimble, able to quickly deal with the large volume of library changes that do not impact backwards compatibility.

In this scenario, the Haskell Prime committee, using a longer deliberative process, would consider the more impactful library changes and batch them up into new reports.

You are absolutely correct that moving the question to the Haskell Prime committee risks pushing the issue around. The idea behind the separation outlined above is to reduce the treadmill; the two bodies use different processes, with different time frames, to arrive at decisions. Some library decisions may deserve a longer deliberative process.

Cheers, Geoff _______________________________________________ Libraries mailing list Libraries@haskell.org javascript:; http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org javascript:; http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Thanks Dan and others on CLC for your hard work and endurance. On 22/10/15 07:48, Simon Peyton Jones wrote:

While we are here, let me say

A BIG THANK YOU TO THE CORE LIBRARIES COMMITTEE

Library design has a lot of detail, and a lot of competing priorities. I am personally very grateful to the CLC for the work they put into this. Like many crucial tasks it's one that often seems to attract more complaints than thanks, but they are doing us all a huge service, and at significant cost in terms of their most precious and inelastic commodity: their personal time.

Remember, as Dan says, before the CLC we no process whatsoever for library evolution... various people made various patches, and there was no way of getting anything substantial done. So we are far far further on than before.

Still not perfect, as my last post said. But still: THANK YOU.

Simon

| -----Original Message----- | From: Dan Doel [mailto:dan.doel@gmail.com] | Sent: 21 October 2015 22:23 | To: Geoffrey Mainland | Cc: Simon Peyton Jones; Augustsson, Lennart; Henrik Nilsson; haskell- | prime@haskell.org List; Haskell Libraries | Subject: Re: Breaking Changes and Long Term Support Haskell | | Hello, | | I'm Dan Doel. I'm on the core libraries committee (though I'm speaking | only for myself). As I recall, one of the reasons I got tapped for it | was due to my having some historical knowledge about Haskell; not | because I was there, but because I've gone back and looked at some old | reports and whatnot (and sometimes think they're better than what we | have now). | | But, I was around (of course) when the core libraries committee | started up, so perhaps I can play the role of historian for this as | well. | | The reason the committee exists is because a couple years ago, people | brought up the ideas that were finally realized in the | Applicative-Monad proposal and the Foldable-Traversable proposal. A | lot of people weighed in saying they thought they were a good idea, | and significantly fewer people weighed in saying they thought that it | shouldn't happen for various reasons---roughly the same things that | people are still bringing up about these proposals. | | This wasn't the first time that happened, either. I think it was | widely agreed among most users that Functor should be a superclass of | Monad since I started learning Haskell around 10 years ago. And once | Applicative was introduced, it was agreed that that should go in the | middle of the two. But it appeared that it would never happen, despite | a significant majority thinking it should, because no one wanted to do | anything without pretty much unanimous consent. | | So, one question that got raised is: why should this majority of | people even use Haskell/GHC anymore? Why shouldn't they start using | some other language that will let them change 15-year-old mistakes, or | adapt to ideas that weren't even available at that time (but are still | fairly old and established, all things considered). And the answer was | that there should be some body empowered to decide to move forward | with these ideas, even if there is some dissent. And frankly, it | wasn't going to be the prime committee, because it hadn't shown any | activity in something like 3 years at the time, and even when it was | active, it didn't make anywhere near the sort of changes that were | being discussed. | | And the kicker to me is, many things that people are complaining about | again (e.g. the FTP) were the very things that the committee was | established to execute. I don't think we had a formal vote on that | proposal, because we didn't need to. Our existence was in part to | execute that proposal (and AMP). And then a year ago, when it was | finally time to release the changes, there was another ruckus. And we | still didn't have a CLC vote on the matter. What we did was conduct a | community poll, and then SPJ reviewed the submissions. But I don't | mean to pass the buck to him, because I'm pretty sure he was worried | that we were crazy, and overstepping our bounds. Just, the results of | the survey were sufficient for him to not overrule us. | | So my point is this: there seems to be some sentiment that the core | libraries committee is unsound, and making bad decisions. But the | complaints are mostly not even about actual decisions we made (aside | from maybe Lennart Augustsson's, where he is unhappy with details of | the FTP that you can blame on us, but were designed to break the least | code, instead of being the most elegant; if we had pleased him more, | we would have pleased others less). They are about the reasons for | founding the committee in the first place. You can blame us, if you | like, because I think it's certain that we would have approved them if | we had formally voted. We just didn't even need to do so. | | Forgive me if I'm wrong, but suggestions that these decisions should | have been deferred to a Haskell Prime committee mean, to me, that the | hope is that they would have been rejected. That the Haskell Prime | committee should have just vetoed these proposals that something like | 80% or more of practicing Haskell users (as far as we can tell) wanted | for years before they finally happened. That the Haskell Prime | committee should be responsible for enforcing the very status quo that | led to the CLC in the first place, where proposals with broad support | but minority dissent never pass for various core modules. | | If this is the case, then one could simply repose the earlier | question: why should most of these people stick around to obey by the | Haskell Prime committee's pronouncements, instead of getting to work | on a language that incorporates their input? | | And if it isn't, then I don't ultimately understand what the | complaints are. We try to accomplish the (large) changes in a manner | that allows transition via refactoring over multiple versions (and as | I mentioned earlier, some complaints are that we compromised _too | much_ for this). And in light of the more recent complaints, it's even | been decided that our time frames should be longer. Rolling up changes | into a report just seems like it makes transitions less smooth. Unless | the idea is to make GHC capable of switching out entire base library | sets; but someone has to implement that, and once you have it, it | makes the report specifications _less_ essential. | | Anyhow, that's my history lesson. Take it as you (all) will. | | Cheers, | -- Dan | | On Wed, Oct 21, 2015 at 10:43 AM, Geoffrey Mainland | wrote: | > On 10/21/2015 07:30 AM, Simon Peyton Jones wrote: | >> Friends | >> | >> I think it's good for us to debate the question of how we should | balance innovation against change; and how we should make those decisions | in future. Geoff's message had some good ideas, especially this bit: | >> | >> | Proposal 2: After a suitable period of discussion on the libraries | list, the | >> | Core Libraries Committee will summarize the arguments for and | against a | >> | proposal and post it, along with a (justified) preliminary decision, | to a | >> | low-traffic, announce-only email list. After another suitable period | of | >> | discussion, they will issue a final decision. What is a suitable | period of | >> | time? Perhaps that depends on the properties of the proposal, such | as | >> | whether it breaks backwards compatibility. | >> | >> Identifying major changes to the libraries, and having a better | publicised, more RFC-like process for deliberating them, would be a good | thing. I believe that the Core Libraries committee is thinking actively | about this. | >> | >> | Personally, I think AMP was the right thing to do, but I don't think | FTP was | >> | the right thing. | >> | >> These make good examples to motivate future changes to our process. | But in the end FTP was subject to a pretty broad deliberative process, | precisely along the lines that Geoff suggests above. We had two clearly- | articulated alternatives, a discrete call for opinions broadcast to every | Haskell channel we could find, a decent interval for people to respond, | and (as it turned out) a very clear preponderance of opinion in one | direction. In a big community, even a broad consultation may yield a | result that some think is ill-advised. That's part of the joyful burden | of being a big community. | >> | >> Let's look forward, not back. I think we can do better in future than | we have done in the past. I don't think we can hope for unanimity, but I | think we can reasonably seek | >> | >> * transparency; | >> * clarity about what decisions are on the table; | >> * broad consultation about decisions that affect | >> a broad constituency; and | >> * a decent opportunity to debate them without having | >> to be involved in massive email threads. Let's try do to that. | >> | >> Simon | >> | >> PS: For what it's worth I'm less keen on Geoff's other proposal: | >> | >> | Proposal 3: A decision regarding any proposal that significantly | affects | >> | backwards compatibility is within the purview of the Haskell Prime | >> | Committee, not the Core Libraries Committee. | >> | >> *Precisely* the same issues will arise whether it's CLC or HPC. And | the HPC is going to be jolly busy with language issues. Moving the | question from one group to another risks avoiding the issue rather than | addressing it. | > | > For the record, I am also not sure Proposal 3 is a good idea :) | > | > However, I do think we could clarify what the respective | > responsibilities of the core libraries committee and Haskell Prime | > committees are. | > | > One possible choice is that the core libraries committee is responsible | > for changes to the core libraries that do not affect libraries in the | > report. It is meant to be nimble, able to quickly deal with the large | > volume of library changes that do not impact backwards compatibility. | > | > In this scenario, the Haskell Prime committee, using a longer | > deliberative process, would consider the more impactful library changes | > and batch them up into new reports. | > | > You are absolutely correct that moving the question to the Haskell Prime | > committee risks pushing the issue around. The idea behind the separation | > outlined above is to reduce the treadmill; the two bodies use different | > processes, with different time frames, to arrive at decisions. Some | > library decisions may deserve a longer deliberative process. | > | > Cheers, | > Geoff | > _______________________________________________ | > Libraries mailing list | > Libraries@haskell.org | > | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haske | ll.org%2fcgi- | bin%2fmailman%2flistinfo%2flibraries&data=01%7c01%7csimonpj%40064d.mgd.mic | rosoft.com%7c6e0a5cbb4f5541caf14108d2da5dc7f8%7c72f988bf86f141af91ab2d7cd0 | 11db47%7c1&sdata=zL3zfXigvfpvdXL%2bhWuGoQzUUhGp%2bg8ofO1tGaFzlvE%3d _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

For proposal 3, I don't see what difference it makes whether a refreshed Haskell committee or a new libraries committee makes decisions that affect backwards compatibility. A name doesn't ensure good decision making. The only difference I can see is that the Haskell committee might only publish final decisions every couple years. But the Haskell report also isn't designed to describe migration plans between feature revisions; unless the plan is to start incorporating library deprecation and whatnot into the report (which would be odd to me). But that would just be doing the same thing slower, so it'd be little different than making library changes over 6 to 9 GHC versions instead of 3. For proposal 2, I don't know how effective it will be in practice. I believe it is already the job of a proposal submitter to summarize the arguments made about it, according to the library proposal guidelines. We could post those summaries to another list. But unless more people promise they will be diligent about reading that list, I'm not sure that one factor in these dust ups (surprise) will actually be any different. Also, if amount of discussion is at issue, I'm not sure I agree. For AMP, I was waiting a decade, more or less. I thought we should do it, other people thought we shouldn't because it would break things. I don't know what more there was to discuss, except there was more stuff to break the longer we waited. As for FTP, some aspects only became known as the proposal was implemented, and I don't know that they would have been realized regardless of how long the proposal were discussed. And then we still had a month or so of discussion after the implementation was finalized, on the cusp of GHC 7.10 being released. So how much more _was_ needed, that people are now discussing it again? If it's just about documenting more things, there's certainly no harm in that. For 1, I don't have a very strong opinion. If pressed, I would probably express some similar sentiments to Henrik. I certainly don't think Haskell would be nearly as good as it is if it were a simple majority vote by all users (and I probably wouldn't use it if that's how things were decided). Would a community vote for libraries committee be better than appointment by people who previously held the power (but have more to do than any human can accomplish)? I don't know. I should say, though, that things are not now run by simple majority vote. What we conducted a year ago was a survey, where people submitted their thoughts. I didn't get to read them, because they were private, and it wasn't my decision to make. But it was not just +80 -20. With regard to your last paragraph, unless I've missed something (and I confess that I haven't read every comment in these threads), the recent resignations didn't express disagreement with the decision making process. They expressed disagreement with the (technical) decisions (and their effects). I don't see how a different process could have solved that unless it is expected that it would have made different decisions. -- Dan On Wed, Oct 21, 2015 at 6:18 PM, Geoffrey Mainland wrote:

Hi Dan,

Thank you for the historical perspective.

I was careful not to criticize the committee. Instead, I made three concrete proposals with the hope that they would help orient a conversation.

It sounds like you are not for proposal 3. How about the other two?

My original email stated my underlying concern: we are losing valuable members of the community not because of the technical decisions that are being made, but because of the process by which they are being made. That concern is what drove my proposals. It is perfectly valid to think that that loss was the inevitable price of progress, but that is not my view.

Cheers, Geoff

On 10/21/15 5:22 PM, Dan Doel wrote:

...

Hello,

I'm Dan Doel. I'm on the core libraries committee (though I'm speaking only for myself). As I recall, one of the reasons I got tapped for it was due to my having some historical knowledge about Haskell; not because I was there, but because I've gone back and looked at some old reports and whatnot (and sometimes think they're better than what we have now).

But, I was around (of course) when the core libraries committee started up, so perhaps I can play the role of historian for this as well.

The reason the committee exists is because a couple years ago, people brought up the ideas that were finally realized in the Applicative-Monad proposal and the Foldable-Traversable proposal. A lot of people weighed in saying they thought they were a good idea, and significantly fewer people weighed in saying they thought that it shouldn't happen for various reasons---roughly the same things that people are still bringing up about these proposals.

This wasn't the first time that happened, either. I think it was widely agreed among most users that Functor should be a superclass of Monad since I started learning Haskell around 10 years ago. And once Applicative was introduced, it was agreed that that should go in the middle of the two. But it appeared that it would never happen, despite a significant majority thinking it should, because no one wanted to do anything without pretty much unanimous consent.

So, one question that got raised is: why should this majority of people even use Haskell/GHC anymore? Why shouldn't they start using some other language that will let them change 15-year-old mistakes, or adapt to ideas that weren't even available at that time (but are still fairly old and established, all things considered). And the answer was that there should be some body empowered to decide to move forward with these ideas, even if there is some dissent. And frankly, it wasn't going to be the prime committee, because it hadn't shown any activity in something like 3 years at the time, and even when it was active, it didn't make anywhere near the sort of changes that were being discussed.

And the kicker to me is, many things that people are complaining about again (e.g. the FTP) were the very things that the committee was established to execute. I don't think we had a formal vote on that proposal, because we didn't need to. Our existence was in part to execute that proposal (and AMP). And then a year ago, when it was finally time to release the changes, there was another ruckus. And we still didn't have a CLC vote on the matter. What we did was conduct a community poll, and then SPJ reviewed the submissions. But I don't mean to pass the buck to him, because I'm pretty sure he was worried that we were crazy, and overstepping our bounds. Just, the results of the survey were sufficient for him to not overrule us.

So my point is this: there seems to be some sentiment that the core libraries committee is unsound, and making bad decisions. But the complaints are mostly not even about actual decisions we made (aside from maybe Lennart Augustsson's, where he is unhappy with details of the FTP that you can blame on us, but were designed to break the least code, instead of being the most elegant; if we had pleased him more, we would have pleased others less). They are about the reasons for founding the committee in the first place. You can blame us, if you like, because I think it's certain that we would have approved them if we had formally voted. We just didn't even need to do so.

Forgive me if I'm wrong, but suggestions that these decisions should have been deferred to a Haskell Prime committee mean, to me, that the hope is that they would have been rejected. That the Haskell Prime committee should have just vetoed these proposals that something like 80% or more of practicing Haskell users (as far as we can tell) wanted for years before they finally happened. That the Haskell Prime committee should be responsible for enforcing the very status quo that led to the CLC in the first place, where proposals with broad support but minority dissent never pass for various core modules.

If this is the case, then one could simply repose the earlier question: why should most of these people stick around to obey by the Haskell Prime committee's pronouncements, instead of getting to work on a language that incorporates their input?

And if it isn't, then I don't ultimately understand what the complaints are. We try to accomplish the (large) changes in a manner that allows transition via refactoring over multiple versions (and as I mentioned earlier, some complaints are that we compromised _too much_ for this). And in light of the more recent complaints, it's even been decided that our time frames should be longer. Rolling up changes into a report just seems like it makes transitions less smooth. Unless the idea is to make GHC capable of switching out entire base library sets; but someone has to implement that, and once you have it, it makes the report specifications _less_ essential.

Anyhow, that's my history lesson. Take it as you (all) will.

Cheers, -- Dan

On Wed, Oct 21, 2015 at 10:43 AM, Geoffrey Mainland wrote:

...

On 10/21/2015 07:30 AM, Simon Peyton Jones wrote:

...

Friends

I think it's good for us to debate the question of how we should balance innovation against change; and how we should make those decisions in future. Geoff's message had some good ideas, especially this bit:

| Proposal 2: After a suitable period of discussion on the libraries list, the | Core Libraries Committee will summarize the arguments for and against a | proposal and post it, along with a (justified) preliminary decision, to a | low-traffic, announce-only email list. After another suitable period of | discussion, they will issue a final decision. What is a suitable period of | time? Perhaps that depends on the properties of the proposal, such as | whether it breaks backwards compatibility.

Identifying major changes to the libraries, and having a better publicised, more RFC-like process for deliberating them, would be a good thing. I believe that the Core Libraries committee is thinking actively about this.

| Personally, I think AMP was the right thing to do, but I don't think FTP was | the right thing.

These make good examples to motivate future changes to our process. But in the end FTP was subject to a pretty broad deliberative process, precisely along the lines that Geoff suggests above. We had two clearly-articulated alternatives, a discrete call for opinions broadcast to every Haskell channel we could find, a decent interval for people to respond, and (as it turned out) a very clear preponderance of opinion in one direction. In a big community, even a broad consultation may yield a result that some think is ill-advised. That's part of the joyful burden of being a big community.

Let's look forward, not back. I think we can do better in future than we have done in the past. I don't think we can hope for unanimity, but I think we can reasonably seek

* transparency; * clarity about what decisions are on the table; * broad consultation about decisions that affect a broad constituency; and * a decent opportunity to debate them without having to be involved in massive email threads. Let's try do to that.

Simon

PS: For what it's worth I'm less keen on Geoff's other proposal:

| Proposal 3: A decision regarding any proposal that significantly affects | backwards compatibility is within the purview of the Haskell Prime | Committee, not the Core Libraries Committee.

*Precisely* the same issues will arise whether it's CLC or HPC. And the HPC is going to be jolly busy with language issues. Moving the question from one group to another risks avoiding the issue rather than addressing it. For the record, I am also not sure Proposal 3 is a good idea :)

However, I do think we could clarify what the respective responsibilities of the core libraries committee and Haskell Prime committees are.

One possible choice is that the core libraries committee is responsible for changes to the core libraries that do not affect libraries in the report. It is meant to be nimble, able to quickly deal with the large volume of library changes that do not impact backwards compatibility.

In this scenario, the Haskell Prime committee, using a longer deliberative process, would consider the more impactful library changes and batch them up into new reports.

You are absolutely correct that moving the question to the Haskell Prime committee risks pushing the issue around. The idea behind the separation outlined above is to reduce the treadmill; the two bodies use different processes, with different time frames, to arrive at decisions. Some library decisions may deserve a longer deliberative process.

Cheers, Geoff _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

| For the record, I am also not sure Proposal 3 is a good idea :) | | However, I do think we could clarify what the respective | responsibilities of the core libraries committee and Haskell Prime | committees are. My instinct is this: Haskell Prime: language Core Libraries Committee: libraries That seems simple. If we try to move the largest and most challenging library design tasks from CLC to HP, I fear that we will overload the latter and devalue the former. | You are absolutely correct that moving the question to the Haskell Prime | committee risks pushing the issue around. The idea behind the separation | outlined above is to reduce the treadmill; the two bodies use different | processes, with different time frames, to arrive at decisions. Some | library decisions may deserve a longer deliberative process. I do agree that some library changes are far-reaching, and need a more deliberative process. I think the CLC is in the process of developing such a process. Moreover, I trust them to be able to tell the difference between low-impact and high-impact changes. That said, as HP moves towards a new language Report, it would be good if CLC similarly moved towards a new libraries Report, so that there was a single unified document, just as we have had to date. Simon