Breaking Changes and Long Term Support Haskell

[Edward Kmett]

On Thu, Oct 22, 2015 at 12:59 PM, Geoffrey Mainland <mainland at apeiron.net>
wrote:

>
> >     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.
> >
> >
> > And on the other hand we also had a concrete proposal that didn't
> > require language changes that was ridiculously popular. People had
> > been talking about Applicative as a superclass of Monad for a decade
> > before we finally acted upon the AMP. People had been talking about
> > superclass defaulting for a decade. When do you cut off discussion and
> > ship the proposal that has overwhelming support? If there is no
> > process that enables this you can stall the process indefinitely by
> > raising objections of this form. Such a situation is not without costs
> > all its own.
> >
>
> I agree. It was certainly within the power of the committee to start a
> clock and say something like "if we don't have a patch to GHC that
> provides backwards compatibility for AMP within 1 year, we will push out
> AMP as-is." Had I understand the implications of AMP at the time, or
> even been aware that AMP was happening (I was actually actively working
> on the GHC code base during that period), that certainly would have been
> motivation for me to do something about it! *That* would be how one
> could cut off discussion and ship a proposal.
>

I freely admit that there is room for improvement in the process. We're all
learning here.

The current Semigroup-Monoid proposal more or less fits the bill you are
looking for here. We have a roadmap today that migrates an existing package
with several years worth of back support into base more or less unmodified,
and then in 3 releases starts requiring instances. You can think of that 3
release clock as precisely what you are looking for here.

If we get an implementation of superclass defaulting or some other
mechanism that can mitigate the extra couple of lines of code that this
proposal will tax users with, within that timeline, we'd gladly incorporate
it into the proposal.


> I am not against changing the Prelude! But it sure would be nice if
> -XHaskell98 gave me a Haskell 98 Prelude and -XHaskell2010 gave me a
> Haskell 2010 Prelude, both of which could be used with external packages
> that themselves used the more modern Prelude.


It would definitely be a preferable state of affairs. Unfortunately, at
least with the tools available to us today, such a plan is incompatible
with any plan that introduces a new superclass. It also cuts off plans that
ever factors an existing class into two, such as the MonadFail proposals.
We simply do not at this time have the technical capabilities that would
support such a system. If they showed up in GHC we can adapt plans to fit.


> Maybe that's impossible.
> Setting a firm deadline to finding a solution to the compatibility issue
> would have been a way to compromise. Ideally, changing the Prelude
> wouldn't require breaking code written to use an older version of the
> Prelude. Yes, attaining that goal would require more work.
>

We looked around for a year for a roadmap that would get us there. None
presented itself. In the end we wound up shedding the core libraries status
of the haskell98 and haskell2010 packages as the 3-4 different ways in
which one could write a Haskell2010 package all have different trade-offs
and can be maintained in user-land.

Examples:

* A hardline version of haskell2010 with a Monad and Num that fully
complies with the report, but which doesn't work with Monad and Num
instances supplied by other libraries. This needs RebindableSyntax, so it
doesn't quite work right. With compiler support for rebinding syntax to a
particular library instead of to whatever is in scope, such a thing might
be suitable for teaching a Haskell class.

* A pragmatic haskell2010 where the Monad has an Applicative superclass and
Num has the current semantic. This works with everything but doesn't
faithfully follow the report.

*  A middle-ground package that tries to use a superclass defaulting
mechanism that we don't have to supply missing Applicative superclasses
might resolve the Applicative-Monad issue in theory, but does nothing for
report compliance of our existing Num.

Each one of these solutions has flaws. Two of them require innovations in
the compiler that we don't have.


> Evolving the Prelude and maintaining compatibility are not necessarily
> mutually exclusive options.
>

Agreed, but as you can see above, maintaining compatibility isn't
necessarily always a viable option either.

-Edward
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151022/99d594d4/attachment.html>