[Haskell-cafe] Backward compatibility

[David Thomas]

I'd also like to see these two.  It occurs to me there may be language
tweak that could reduce breakage and add some convenience in both cases.
It would not surprise me at all if this has been thought of, examined, and
discarded, but I don't have time to dig so I'll just lay it out quickly,
and if it has been discussed before someone will probably know where.

The idea is to allow definitions of superclass operations in subclass
instances.  If there are such definitions, it's treated as if there were
instances defined for each class (potentially a source translation, even).
I think default definitions of superclass operations in the subclass would
be used last (that is, only for the automatic instance of the superclass,
and only if the superclass didn't have a default for that).

This should allow existing instances of Num to just work (and I think Monad
too, with some care).  It would also mean if you're making something that's
a Monad or a Num you could just lay out the one instance in all one place,
reducing a bit of boilerplate.  At the same time, you'd have the
flexibility to just use the superclasses where you just want pieces.


On Fri, May 3, 2013 at 3:23 AM, Guy <guytsalmaves-h at yahoo.com> wrote:

> Ertugrul Söylemez wrote:
>
>> Often demanded changes that may or may not happen in the future:
>>
>>    * base: Make Functor a superclass of Monad.  One of the two most
>>      commonly demanded change to the base library.  Will break lots and
>>      lots of code.  Reason:  Would greatly simplify a lot of code.
>>
>>    * base: Fix the numeric type classes.  The other most commonly
>>      demanded change.  Will break lots and lots of code, including most
>>      of the base library.  Reason:  Would make numeric code much more
>>      sensible and algebraic.
>>
>
> That's what I thought of when I saw the original complaint - GHC is too
> backwards compatible! There's far too much boilerplate because of the
> Functor => Applicative => Monad mess. Float/Double being Enums is
> ridiculous. None of this gets fixed because of the fear that new GHC won't
> compile old code.
>
> Perhaps we need some system for maintainers to vote on whether they
> consider the value of a breaking change to be worth the effort of fixing
> their packages to work with it. In my own code, I usually find that this
> effort is minor, and I'm more than happy to do it in return for a better
> language/library.
>
> PS The proposal to fix Functor => Applicative => Monad has patches
> attached for GHC and base, but the backwards compatibility bogeyman always
> seems to trump something that will break a lot of code.
>
>
>
> ______________________________**_________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/**mailman/listinfo/haskell-cafe<http://www.haskell.org/mailman/listinfo/haskell-cafe>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20130503/60aea18a/attachment.htm>