Breaking Changes and Long Term Support Haskell

[Geoffrey Mainland]

On 10/22/2015 11:02 AM, Matthias Hörmann wrote:
> I would say that the need to import Control.Applicative in virtually
> every module manually
> definitely caused some pain before AMP.

In this particular case, there is a trade off between breaking code on
the one hand and having to write some import statements on the other. I
find writing some extra imports less painful than breaking (other
people's and my) code, but the other position is defensible as well. I
sense that I am in the minority, at least on the libraries list.

> I would also argue that a
> non-negligible amount
> of effort goes into teaching the warts, the reasons for the warts and
> how to work around them.

Which wart(s) in particular? All of them? Does having return (and (>>))
in Monad make teaching more difficult?

I teach Haskell beginners, and I found that AMP made explaining monads
slightly more difficult because it served as a source of confusion for
my students.

On the other hand, the warts provide a teachable moment once students
understand all this stuff :)

>> Dealing with AMP? I'm working on a collaborative research project that is stuck on 7.8 because of AMP.
> I am curious what exactly about AMP causes your research project to be
> "stuck" on GHC 7.8
> considering we have had multiple people mention how little effort it
> took to update even large codebases.
> I think it would be useful information to have to plan future changes
> in a way that might avoid
> your issues.

I was hoping that mentioning this wouldn't distract from the three main
(numbered) questions I posed below. Alas.

If I were working alone, AMP wouldn't be a huge deal. I could fix the
code for 7.10 compatibility, but then unless everyone switches to 7.10,
changes to the codebase made by someone using 7.8, e.g., defining a new
Monad instance, could break things on 7.10 again. It's easier to stick
with 7.8. Any time spent dealing with compatibility issues is time not
spent writing actual code.

I outlined one possible path to avoid this kind of issue: spend more
time thinking about ways to maintain compatibility. We had proposals for
doing this with AMP.

Cheers,
Geoff

>
> On Thu, Oct 22, 2015 at 3:29 PM, Geoffrey Mainland <mainland at apeiron.net> wrote:
>> 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