I see, thanks for all this information! Here must be the answer of why, possibly, liftM is written in terms of monads and not of fmap.<br>Yes I was saying "not heavywork" at the time I didn't know you could create an instance of Monad and use its methods to fill the superclasses even though intuitively it looked like the Monad instance couldn't be accepted if the superclass weren't already.<br>Does anyone have an explanation for this?<br><br>Le samedi 30 avril 2016, Daniel Bergey <<a href="mailto:bergey@alum.mit.edu">bergey@alum.mit.edu</a>> a écrit :<br>> On 2016-04-30 at 15:14, Silent Leaf <<a href="mailto:silent.leaf0@gmail.com">silent.leaf0@gmail.com</a>> wrote:<br>>> I think I got what exactly was the change of ghc 7.10. basically it only adds a<br>>> constraint Applicative on the Monad class, and same with<br>>> Functor/Applicative.<br>><br>> 7.10 adds the constraint on the Monad class.  Prior to 7.10, both Monads<br>> and Applicatives already needed to be Functors.<br>><br>>> Otherwise it's forcing the programmer to do even more possibly-useless<br>>> work (we don't always need applicative and functors for every use of a<br>>> new monad, do we?)<br>><br>> The practical advantage comes when I want to write some code that is<br>> generic over Monads.  If I can't assume that every Monad is Applicative,<br>> my choices are:<br>><br>> 1) Write (Applicative m, Monad m) =>, and not work for those Monads<br>> 2) Write `ap` everywhere I mean <*>, which for some instances is less<br>> efficient<br>> 3) Write two versions, one like (1) and one like (2)<br>><br>> None of these are very appealing, and orphan instances are a pain, so<br>> there's already strong social pressure that any Monad instance on<br>> Hackage should have the corresponding Applicative instance defined.<br>><br>>> in short i think if they wanted mathematical correctness they should<br>>> have added automatic instanciation of superclasses, with possibility<br>>> to override the default definitions, like they do so with some<br>>> superfluous methods.<br>><br>> Several ways of automatically defining superclasses were discussed as<br>> part of the AMP changes.  Maybe we'll get one in some future GHC.  I<br>> don't know the details, but some of the discussion:<br>><br>> <a href="https://ghc.haskell.org/trac/ghc/wiki/IntrinsicSuperclasses">https://ghc.haskell.org/trac/ghc/wiki/IntrinsicSuperclasses</a><br>> <a href="https://ghc.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances">https://ghc.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances</a><br>> <a href="https://ghc.haskell.org/trac/ghc/wiki/InstanceTemplates">https://ghc.haskell.org/trac/ghc/wiki/InstanceTemplates</a><br>><br>>> Not that write functors or applicative functor instances is actually heavywork, of<br>>> course, thankfully.<br>><br>> You know that if the instances are all in the same module, you can use<br>> the Monad functions, right?  So the extra work is just pasting in:<br>><br>>  instance Functor m where<br>>     fmap = liftM<br>><br>> instance Applicative m where<br>>     pure  = return<br>>     (<*>) = ap<br>>