Breaking Changes and Long Term Support Haskell

[Edward Kmett]

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

> On 10/22/2015 01:29 PM, Edward Kmett wrote:
> > On Thu, Oct 22, 2015 at 12:59 PM, Geoffrey Mainland
> > <mainland at apeiron.net <mailto:mainland at apeiron.net>> wrote:
> >
> >
> >     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.
>
> Great!
>
> Could we work to characterize what technical capabilities we would need
> to support full backwards Prelude compatibility?
>
> Here is my rough understanding of what we would need:
>
> 1) Some method for "default superclasses." This would solve the AMP issue.
>
> 2) A method for factoring existing classes into two (or more) parts.
> This would solve the MonadFail problem.
>
> 3) A method for imposing extra superclass constraints on a class. This
> would be needed for full Num compatibility. Seems much less important
> that 1 and 2.
>
> The most thought has gone into 1.
>

> Are these three technical capabilities *all* that we would need? Perhaps
> we also need a way to tie the current language (-XHaskell98,
> -XHaskell2010) to a particular implementation of the Prelude.
>

I don't have a concrete plan here. I'm not even sure one can be achieved
that works. I'd say that the burden of figuring out such a thing falls on
the party that can create a plan, pitch it to the community and potentially
implement it.

If I enumerate a set of conditions here I'm basically implying that I'd
agree to any plan that incorporated them. I'm just not prepared to make
that commitment sight-unseen to something with unknown warts and
implications.

I can, however, say that it is plausible that what you have enumerated
above could potentially address the outstanding issues, but I don't know
how good of a compromise the result would be.

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