
Yes true, subclass, mixed up the terms. ^^
Ah true, I heard about this Dániel. But then it would be generalized to all classes, or just those three ones?
Anyway, trying the same with Applicative and its *sub*class Monad:
pure = return (<*>) :: Monad m => m (a -> b) -> m a -> m b mf <*> ma = let mg = mf >>= \f -> return (return . f) in mg >>= \g -> (ma >>= g) As: f :: a -> b return . f :: Monad m => a -> m b mg :: Monad m => m (a -> m b)
Is there an easier solution? It's easy enough, but not as trivial as for Applicative => Functor.
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...
Why do we write constraints like that:
Functor f => (a -> b) -> f a -> f b or: Functor f => Applicative f 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?)
Lol, well I said "thanks both" but actually there's only one person. Don't
mind me I'm drunk.
Le vendredi 29 avril 2016, Silent Leaf
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.
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.
Thanks both for your answers!
Le vendredi 29 avril 2016, Dániel Arató
a écrit : Oh, and by the way, is it enough then to create an instance of
Applicative
or Monad to automatically get an instance of the respective superclasses? And the generalization for any superclass/subclass? Would be great... If not why so?
I think the latest GHC should be able to give you the superclass instances like you said. Before GHC 7.10 the class hierarchy was a bit disjointed: a Monad was not necessarily an Applicative (even though it should be). https://wiki.haskell.org/Functor-Applicative-Monad_Proposal
Daniel _______________________________________________ Beginners mailing list Beginners@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners