[Haskell-cafe] Applicative of Applicative

[Tikhon Jelvis]

There are two equivalent definitions of monad: one in terms of (>>=) and
one in terms of fmap and join. Given (>>=), we can define join and fmap as

    join :: Monad m => m (m a) -> m a
    join x = x >>= id

Given the join and fmap, we can define (>>=) as

    (>>=) :: Monad m => m a -> (a -> m b) -> m b
    x >>= f = join (fmap f x)

This is why some other languages like Scala call (>>=) flatMap: it's the
combination of flattening (join) and mapping (fmap).

Personally, much of the time, I find join more intuitive for a given monad
than (>>=), but (>>=) is more useful for everyday code so it's included in
the class by default. Recently, there was a move to add join to the class
so that you could choose which one to implement, but that ran into some
technical difficulties and had to be postponed.

As far as time-varying code goes, you were right in your intuition that
it's closely related to FRP. You have, in fact, come up with a type similar
to events in classical FRP—an accomplishment on its own! I found Conal
Elliott's "Push-Pull Functional Reactive Programming"[1] to have a good
overview of existing ideas in this vein, including a discussion of the
relevant Functor/Applicative/Monad instances.

My understanding is that while the monad instance for this temporal type is
well-defined, current libraries do not implement it for performance
reasons. It's difficult to enable this sort of logic without exposing
potential memory leaks, which make practical programming in the style
significantly more difficult. But the conceptual ideas are all entirely
sound!

On Tue, Mar 24, 2015 at 10:17 AM, martin <martin.drautzburg at web.de> wrote:

> Hey guys, you made my day.
>
> I had considered making it a monad, but I couldn't figure out what a->mb
> is supposed to mean in this context and so I
> thought it was just an Applicative Functor. The idea that the presence of
> join makes it a monad was not obvious to me.
>
> Now I can see the light. I can now imagine how I can have a Temporal
> Schedule which switches from "Winter Schedule" to
> "Summer Schedule" at June 1st and a function which takes such a schedule
> and populates it with some Temporal Data.
>
> Way cool. Does the rest of the world know that you haskellers can do such
> things?
>
> > @M Farkas-Dyck
> > I assume (pure = return) would make its argument time-invariant.
>
> Exactly!
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150324/5d6dfe0d/attachment.html>