I didn't get this version of ghc already existed! it seems I have it, i'll thus check all that ASAP.<br>Technical question: class constraints should not be written in definitions of instances too, right? Wouldn't be "parametric" anymore and all:<br>> instance Applicative Maybe => Monad Maybe where ...<br>I don't think I've ever seen something like that but I'm asking just in case, esp as it might precisely be the way to write implied superclasses in the latest ghc(?)<br><br>Indeed, your definition of (<*>) in terms of monads is much simpler to read! I think I was too much centered on finding a way to replicate the types, to more simply find a way to replicate directly what does the function.<br>Obviously, my def can become yours by some simple operations.<br>Mine:<br>> let left = mf >>= \f -> return $ return . f<br>>     right = \mg -> ma >>= mg<br>> in left >>= right<br>Here with mg = return . f eventually (when called).<br><br>Two things bound together, the wrapped value of left (== return.f) being the parameter of the function right. It's clear that the wrapped result is just wrapped so it can be unwrapped immediately after. Might as well not wrap it at all in the first place, and do everything in the first bind operation:<br>> mf >>= \f -> let mg = return . f in ma >>= mg<br>and of course, (mg == \a -> return $ f a).<br><br>Anyway, yeah that's also how I read (=>) arrows, obviously, how else to do? ^^ It's just, as most of the syntax and terminology of haskell is based on what looks like very solid math roots, I imagined the syntax for constraints was also justified mathematically somehow.<br><br>Le vendredi 29 avril 2016, Dániel Arató <<a href="mailto:exitconsole@gmail.com">exitconsole@gmail.com</a>> a écrit :<br>> For a drunk person you're getting these equivalences surprisingly right. :)<br>><br>>>> Ah true, I heard about this Dániel. But then it would be generalized to<br>>> all classes, or just those three ones?<br>><br>> It would make sense for it to work for any class hierarchy, but<br>> honestly I just don't know and I've got an old GHC on my laptop so I<br>> can't check. Maybe someone who actually knows will come along and<br>> enlighten us. ¯\_(ツ)_/¯<br>><br>>>> Anyway, trying the same with Applicative and its *sub*class Monad:<br>>>>> pure = return<br>><br>> That's right.<br>><br>>>>> mf <*> ma =<br>>>>    let mg = mf >>= \f -> return (return . f)<br>>>>    in mg >>= \g -> (ma >>= g)<br>><br>>>> Is there an easier solution? It's easy enough, but not as trivial as for<br>>> Applicative => Functor.<br>><br>> I've got (an alpha-equivalent of) the following on a scrap piece of paper:<br>> mf <*> mx = mf >>= \f -> mx >>= \x -> return . f $ x<br>><br>> It reads nice and fluent.<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>><br>> That's a very good question. I agree that it would make a bit more<br>> sense if the arrows were reversed.<br>> I think it helps to read<br>> "Functor f => Applicative f where ..."<br>> as<br>> "if you've got a Functor then you can have an Applicative if you just<br>> implement these functions"<br>> as opposed to<br>> "if f is a Functor that implies that f is an Applicative" (wrong).<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>>