Breaking Changes and Long Term Support Haskell

[Dan Doel]

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
<mainland at 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
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries