Yes true, subclass, mixed up the terms. ^^ <br><br>Ah true, I heard about this Dániel. But then it would be generalized to all classes, or just those three ones?<br><br>Anyway, trying the same with Applicative and its *sub*class Monad:<br>> pure = return<br>> (<*>) :: Monad m => m (a -> b) -> m a -> m b<br>> mf <*> ma =<br>    let mg = mf >>= \f -> return (return . f)<br>    in mg >>= \g -> (ma >>= g)<br>As:<br>> f :: a -> b<br>> return . f :: Monad m => a -> m b<br>> mg :: Monad m => m (a -> m b)<br><br>Is there an easier solution? It's easy enough, but not as trivial as for Applicative => Functor.<br><br>Which leads me to one question I have for a long now. I haven't found my answer, but perhaps did I not search at the right place...<br><br>Why do we write constraints like that:<br>> Functor f => (a -> b) -> f a -> f b<br>or:<br>> Functor f => Applicative f<br>I'm far from an expert in Math, but I'm used to reading (=>) as an implication, but maybe is it completely different? At any rate, if it were an implication, i'd expect it to be written for example (Applicative f => Functor f), to denote maybe that anything being an Applicative should also be a functor (everything in the first is (= must be, in declarative terms) in the second). I mean if we see a class as a set of types (can we btw?) then if A(pplicative) is superclass of M(onad), A is a superset of M, because (m in M) => (m in A), hence the direction of the implication arrow, Monad => Applicative.<br><br>Same thing for types of function (and other values), eg (a -> b => Num a), the type of the function would imply some constraint, which would therefore imply that no type that doesn't respect the implied term (constraint) can pretend to be "part" of the type of the function/value.<br><br>Maybe I'm misinterpreting the purpose or meaning, but I still wonder what is the actual meaning then of those (=>) arrows as they don't *seem* to be implications in the mathematical meaning I'd intuitively imagine.<br><br>Thanks both for your answers!<br><br>Le vendredi 29 avril 2016, Dániel Arató <<a href="mailto:exitconsole@gmail.com">exitconsole@gmail.com</a>> a écrit :<br>>> Oh, and by the way, is it enough then to create an instance of Applicative<br>>> or Monad to automatically get an instance of the respective superclasses?<br>>> And the generalization for any superclass/subclass? Would be great... If<br>>> not why so?<br>><br>> I think the latest GHC should be able to give you the superclass<br>> instances like you said. Before GHC 7.10 the class hierarchy was a bit<br>> disjointed: a Monad was not necessarily an Applicative (even though it<br>> should be).<br>> <a href="https://wiki.haskell.org/Functor-Applicative-Monad_Proposal">https://wiki.haskell.org/Functor-Applicative-Monad_Proposal</a><br>><br>> Daniel<br>> _______________________________________________<br>> Beginners mailing list<br>> <a href="mailto:Beginners@haskell.org">Beginners@haskell.org</a><br>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners">http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners</a><br>>