[Haskell-cafe] FRP: Why is Behavior not a Monad?
ivan.perez at keera.co.uk
Sat Jan 20 17:02:32 UTC 2018
We do have them in Dunai , which combines both arrowized and classic FRP
in an efficient and elegant solution. Yampa  (Arrowized FRP) can be
built on top of Dunai and we have real games and apps running on top of
The issue is described very well in Section 2, "Efficient and Compositional
Higher-Order Streams", by Gergely Patai .
On 20 January 2018 at 09:00, martin <martin.drautzburg at web.de> wrote:
> Hello all,
> it appears to be difficult to define a Monad instance for Behavior and in
> many (if not all) reactive libraries Behavior
> is not a Monad. Why is that so?
> If a Beahvior is conceptionally a function from Time to something,
> newtype Behavior a = Behavior (Time -> a)
> then its Monad instance should work like a Reader Monad.
> Alternatively one can look at the join function
> join :: Behavior (Behavior a) -> Behavior a.
> This corresponds to the situation where you switch between Channels on a
> TV remote controle and each Channel is a
> behavior of Image. Then
> join Behavior (Behavior image)
> should give you the video stream you see on the screen. How can one
> possibly live without this operation?
> I assume this has something to do with the actual implementation and not
> so much with the semantics, because
> semantically I don't see any problems.
> - why is Behavior not a Monad and
> - how would you express the TV-remote example without a Monad?
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe