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.d...@gmail.com] > | Sent: 21 October 2015 22:23 > | To: Geoffrey Mainland > | Cc: Simon Peyton Jones; Augustsson, Lennart; Henrik Nilsson; haskell- > | pr...@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 > | <mainl...@apeiron.net> 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 > | > librar...@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 > _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
