Altering Class hierarchy

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Altering Class hierarchy

Frantisek Farka
Hi all,

I was toying with Haskell classes and came across
Functor-Applicative-Monad proposal[1]. It shows out that adding
a super class (Applicative) to a class (Monad) is not an easy task when
the class hierarchy is already in use.

In this case it result in stepwise approach (step1 e. g. [2]) in order
not to break already existing code which uses Monad.

I am interested in other examples of such changes. Which alterings of
your class hierarchy do you usually need when rewriting your code? I
don't mean only adding superclass here, other modifications could be
also handy, e. g. dropping out a class or splitting a class into two.

Can you point me to some actual examples on real source code? How do
you deal with this kind of problem on your projects?

Thanks for a reply :)

FF


[1]
http://www.haskell.org/haskellwiki/Functor-Applicative-Monad_Proposal
[2] https://ghc.haskell.org/trac/ghc/ticket/8004

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Altering Class hierarchy

Stephen Tetley-2
The Functor-Applicative-Monad hierarchy change has been a difficult
change _because_ Functor and Monad are primary parts to the Prelude
(standard library). Individual projects don't change the standard
library, so changing a class hierarchy is no more problematic than any
other substantial / breaking change to a code base.

Best wishes

Stephen
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe