Breaking Changes and Long Term Support Haskell

[Geoffrey Mainland]

On 10/22/2015 02:40 AM, Edward Kmett wrote:
> On Wed, Oct 21, 2015 at 8:42 PM, Gregory Collins
> <greg at gregorycollins.net <mailto:greg at gregorycollins.net>> wrote:
>
>
>     On Wed, Oct 21, 2015 at 3:18 PM, Geoffrey Mainland
>     <mainland at apeiron.net <mailto:mainland at apeiron.net>> wrote:
>
>         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.
>
>     [If] you're doing research you're on the treadmill, almost by
>     definition, and you're delighted that we're finally making some
>     rapid progress on fixing up some of the longstanding warts.
>
>     If you're a practitioner, you are interested in using Haskell for,
>     y'know, writing programs. You're probably in one of two camps:
>     you're in "green field" mode writing a lot of new code (early
>     stage startups, prototype work, etc), or you're
>     maintaining/extending programs you've already written that are out
>     "in the field" for you doing useful work. Laura Wingerd calls this
>     the "annealing temperature" of software, and I think this is a
>     nice metaphor to describe it. How tolerant you are of ecosystem
>     churn depends on what your temperature is: and I think it should
>     be obvious to everyone that Haskell having "success" for
>     programming work would mean that lots of useful and correct
>     programs get written, so everyone who is in the former camp will
>     cool over time to join the latter.
>
>
>     I've made the point before and I don't really want to belabor it:
>     our de facto collective posture towards breaking stuff, especially
>     in the past few years, has been extremely permissive, and this
>     alienates people who are maintaining working programs.
>
>
> Even among people who purported to be teaching Haskell or using
> Haskell today in industry the margin of preference for the concrete
> FTP proposal was ~79%. This was considerably higher than I expected in
> two senses. One: there were a lot more people who claimed to be in one
> of those two roles than I expected by far, and two: their appetite for
> change was higher than I expected. I initially expected to see a
> stronger "academic vs. industry" split in the poll, but the groups
> were only distinguishable by a few percentage point delta, so while I
> expected roughly the end percentage of the poll, based on the year
> prior I'd spent running around the planet to user group meetings and
> the like, I expected it mostly because I expected more hobbyists and
> less support among industrialists.
>
>     I'm actually firmly of the belief that the existing committee
>     doesn't really have process issues, and in fact, that often it's
>     been pretty careful to minimize the impact of the changes it wants
>     to make. As others have pointed out, lots of the churn actually
>     comes from platform libraries, which are out of the purview of
>     this group.
>
>
> Historically we've had a bit of a split personality on this front.
> Nothing that touches the Prelude had changed in 17 years. On the other
> hand the platform libraries had maintained a pretty heavy rolling wave
> of breakage the entire time I've been around in the community. On a
> more experimental feature front, I've lost count of the number of
> different things we've done to Typeable or template-haskell.
>  
>
>     All I'm saying is that if we want to appeal to or cater to working
>     software engineers, we have to be a lot less cavalier about
>     causing more work for them, and we need to prize stability of the
>     core infrastructure more highly. That'd be a broader cultural
>     change, and that goes beyond process: it's policy.
>
>
> The way things are shaping up, we've had 17 years of rock solid
> stability, 1 release that incorporated changes that were designed to
> minimize impact, to the point that the majority of the objections
> against them are of the form where people would prefer that we broke
> _more_ code, to get a more sensible state. Going forward, it looks
> like the next 2 GHC releases will have basically nothing affecting the
> Prelude, and there will be another punctuation in the equilibrium
> around 8.4 as the next set of changes kicks in over 8.4 and 8.6 That
> gives 2 years worth of advance notice of pending changes, and a pretty
> strong guarantee from the committee that you should be able to
> maintain code with a 3 release window without running afoul of
> warnings or needing CPP.
>
> So, out of curiosity, what additional stability policy is it that you
> seek?

Thanks to you and Dan [1], I now have a greater understanding and
appreciation for where the committee has been coming from. My new
understanding is that the changes that were formalized in AMP, FTP, and
MRP were the basis for the committee's creation. It also seems that
there are more changes in the pipeline that have not yet been made into
proposals, e.g., pulling (>>) out of Control.Monad [2]. Part of
"stability" is signaling change as far ahead as possible. The committee
has put a lot of effort into this, which I appreciate! However, as each
of these proposal has come down the pipeline, I never realized that they
were part of a larger master plan.

1) What is the master plan, and where is it documented, even if this
document is not up to the standard of a proposal? What is the final
target, and when might we expect it to be reached? What is in the
pipeline after MRP?

Relatedly, guidance on how to write code now so that it will be
compatible with future changes helps mitigate the stability issue.

2) How can I write code that makes use of the Prelude so that it will
work with every new GHC release over the next 3 years? 5 years? For
example, how can I write a Monad instance now, knowing the changes that
are coming, so that the instance will work with every new GHC release
for the next 3 years? 5 years? If the answer is "you can't," then when
might I be able to do such a thing? As of 8.4? 8.6? I'm embarrassed to
say I don't know the answer!

Finally, if none of these changes broke Prelude backwards compatibility,
far fewer people would be complaining :) Of course, we can't always make
progress without breaking things, but a more deliberative process might
offer an opportunity to make progress while still preserving backwards
compatibility. Take AMP for example. There were at least two [3] [4]
proposals for preserving backwards compatibility. Investigating them
would have taken time and delayed AMP, yes, but why the rush?

3) Can we have a process that allows more deliberation over, and wider
publicity for, changes that break backwards compatibility? The goal of
such a process would not be to prevent change, but to allow more time to
find possible solution to the issue of backwards compatibility.

My proposal for a low-traffic mailing list where all proposals were
announced was meant to provide wider publicity.

Personally, I think these proposals do indeed fix a lot of warts in the
language. As a researcher who uses actively uses Haskell every day,
these warts have had approximately zero impact on me for the past
(almost) decade, and I would be perfectly content if they were never
fixed. The only pain I can recall enduring is having to occasionally
write an orphan Applicative instance. I have been importing Prelude
hiding mapM for years. I have been importing Control.Applicative for
years. Neither has been painful. Dealing with AMP? I'm working on a
collaborative research project that is stuck on 7.8 because of AMP. I
agree, that seems silly, but whether or not it is silly, it is an impact
I feel.

One way to look at these proposals is to ask the question "Wouldn't the
language be nicer if all these changes were made?" Another is to ask the
question "Does the fact that these changes have not been made make your
life as a Haskell programmer more difficult in any significant way?" I
answer "yes" to the former and "no" to the latter. Is our stance that
answering "yes" to the former question is enough to motivate braking
change? Shouldn't a answer "no" to the latter question cause some
hesitation?

Maybe there are a lot of people who answer "yes" to both questions. I
would like to know! But does having return in the Monad class really
cause anyone anything other than existential pain?

Cheers,
Geoff

[1] https://mail.haskell.org/pipermail/libraries/2015-October/026390.html
[2] https://mail.haskell.org/pipermail/libraries/2015-September/026158.html
[3] https://ghc.haskell.org/trac/ghc/wiki/InstanceTemplates
[4] https://ghc.haskell.org/trac/ghc/wiki/IntrinsicSuperclasses