<div dir="ltr"><div><div><div><div><div><div><div><div><div>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<br><br></div>    join :: Monad m => m (m a) -> m a<br></div>    join x = x >>= id<br><br></div>Given the join and fmap, we can define (>>=) as<br><br></div>    (>>=) :: Monad m => m a -> (a -> m b) -> m b<br></div>    x >>= f = join (fmap f x)<br><br></div>This is why some other languages like Scala call (>>=) flatMap: it's the combination of flattening (join) and mapping (fmap).<br><br></div>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.<br><br></div>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.<br><br></div>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!<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 24, 2015 at 10:17 AM, martin <span dir="ltr"><<a href="mailto:martin.drautzburg@web.de" target="_blank">martin.drautzburg@web.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey guys, you made my day.<br>
<br>
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<br>
thought it was just an Applicative Functor. The idea that the presence of join makes it a monad was not obvious to me.<br>
<br>
Now I can see the light. I can now imagine how I can have a Temporal Schedule which switches from "Winter Schedule" to<br>
"Summer Schedule" at June 1st and a function which takes such a schedule and populates it with some Temporal Data.<br>
<br>
Way cool. Does the rest of the world know that you haskellers can do such things?<br>
<br>
> @M Farkas-Dyck<br>
<span class="">> I assume (pure = return) would make its argument time-invariant.<br>
<br>
</span>Exactly!<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
</div></div></blockquote></div><br></div>