Breaking Changes and Long Term Support Haskell

[Edward Kmett]

On Thu, Oct 22, 2015 at 1:37 PM, Gregory Collins <greg at gregorycollins.net>
wrote:

>
> On Wed, Oct 21, 2015 at 11:40 PM, Edward Kmett <ekmett at gmail.com> wrote:
>
>> 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
>>
>
> I have >95% confidence that all of the C++ programs I wrote 15 years ago
> would build and work if I dusted them off and typed "make" today. I have
> Haskell programs I wrote last year that I probably couldn't say that about.
>
> So I don't buy that, at all, at least if we're discussing the topic of the
> stability of the core infrastructure in general rather than changes being
> made to the Prelude. It's been possible to write to Haskell 98 without too
> much breakage, yes, but almost nobody actually does that; they write to
> Haskell as defined by GHC + the boot libraries + Haskell platform +
> Hackage, IMO with decreasing expectations of stability for each. The core
> set breaks a lot.
>

I definitely agree here.

We have a lot of libraries in the Haskell Platform that have fairly liberal
change policies. On the other hand, we have a policy of "maintainer
decides" around issues. This yields a fairly decentralized change
management process, with different maintainers who have different views.
The Platform gives us a central pool of packages that are generally the
"best of breed" in their respective spaces, but gives us few stability
guarantees.

Heck, every release I wind up having to change whatever code I have that
uses template-haskell or Typeable.

On the other hand, it isn't clear with a larger "core" platform with harder
stability guarantees that we have a volunteer force that can and would sign
up for the long slog of maintenance without that level of autonomy.


> We definitely shouldn't adopt a posture to breaking changes as
> conservative as the C++ committee's, and literally nobody in the Haskell
> community is arguing against breaking changes in general, but as I've
> pointed out, most of these breakages could have been avoided with more
> careful engineering, and indeed, on many occasions the argument has been
> made and it's fallen on deaf ears.
>

I would argue that there are individual maintainers that give lie to that
statement. In many ways Johan himself has served as a counter-example
there. The libraries he has maintained have acted as a form of bedrock with
long maintenance windows. On the other hand, the burden of maintaining that
stability seems to have ultimately burned him out.

They can speak for themselves but I think for Mark and Johan, this is a
> "straw that broke the camel's back" issue rather than anything to do with
> the merits of removing return from Monad. I think the blowback just happens
> to be so much stronger on MRP because the breaking change is so close to
> the core of the language, and the benefits are so nebulous. fixing an
> aesthetic problem has almost zero practical value
>

I personally don't care about the return side of the equation.

Herbert's MRP proposal was an attempt by him to finish out the changes
started by AMP so that a future Haskell Report can read cleanly. Past
reports have been remarkably free of historical baggage.

I'd personally readily sacrifice "progress" there in the interest of
harmony. Herbert as haskell-prime chair possibly feels differently.


> and ">> could be slightly more efficient for some monads" is pretty weak
> sauce.
>

The issue right now around (>>) is that it has knock-on effects that run
pretty far and wide. "Weak sauce" or not, it means through second order
consequences that we can't move the useless mapM and sequence to the top
level from their current status as memberrs of Traversable and that users
have to care about which of two provably equivalent things that they are
using, at all times.

It means that code that calls mapM will be less efficient and that mapM_
behaves in a manner with rather radically different space and time behavior
than mapM today and not in a consistently good way.

-Edward
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-prime/attachments/20151022/1c1cc4be/attachment-0001.html>