[Haskell-beginners] Trying to prove Applicative is superclass of Functor, etc

[Silent Leaf]

I didn't get this version of ghc already existed! it seems I have it, i'll
thus check all that ASAP.
Technical question: class constraints should not be written in definitions
of instances too, right? Wouldn't be "parametric" anymore and all:
> instance Applicative Maybe => Monad Maybe where ...
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(?)

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.
Obviously, my def can become yours by some simple operations.
Mine:
> let left = mf >>= \f -> return $ return . f
>     right = \mg -> ma >>= mg
> in left >>= right
Here with mg = return . f eventually (when called).

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:
> mf >>= \f -> let mg = return . f in ma >>= mg
and of course, (mg == \a -> return $ f a).

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.

Le vendredi 29 avril 2016, Dániel Arató <exitconsole at gmail.com> a écrit :
> For a drunk person you're getting these equivalences surprisingly right.
:)
>
>>> Ah true, I heard about this Dániel. But then it would be generalized to
>> all classes, or just those three ones?
>
> It would make sense for it to work for any class hierarchy, but
> honestly I just don't know and I've got an old GHC on my laptop so I
> can't check. Maybe someone who actually knows will come along and
> enlighten us. ¯\_(ツ)_/¯
>
>>> Anyway, trying the same with Applicative and its *sub*class Monad:
>>>> pure = return
>
> That's right.
>
>>>> mf <*> ma =
>>>    let mg = mf >>= \f -> return (return . f)
>>>    in mg >>= \g -> (ma >>= g)
>
>>> Is there an easier solution? It's easy enough, but not as trivial as for
>> Applicative => Functor.
>
> I've got (an alpha-equivalent of) the following on a scrap piece of paper:
> mf <*> mx = mf >>= \f -> mx >>= \x -> return . f $ x
>
> It reads nice and fluent.
>
>>> Why do we write constraints like that:
>>>> Functor f => (a -> b) -> f a -> f b
>>> or:
>>>> Functor f => Applicative f
>
> That's a very good question. I agree that it would make a bit more
> sense if the arrows were reversed.
> I think it helps to read
> "Functor f => Applicative f where ..."
> as
> "if you've got a Functor then you can have an Applicative if you just
> implement these functions"
> as opposed to
> "if f is a Functor that implies that f is an Applicative" (wrong).
>
> Daniel
> _______________________________________________
> Beginners mailing list
> Beginners at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/beginners/attachments/20160429/29f204ef/attachment.html>