We do have them in Dunai [1], which combines both arrowized and classic FRP in an efficient and elegant solution. Yampa [2] (Arrowized FRP) can be built on top of Dunai and we have real games and apps running on top of this [3].

The issue is described very well in Section 2, "Efficient and Compositional Higher-Order Streams", by Gergely Patai [4].

Ivan

[1] http://github.com/ivanperez-keera/dunai
[2] http://github.com/ivanperez-keera/Yampa
[3] http://www.cs.nott.ac.uk/~psxip1/#FRPRefactored
[4] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.182.2374&rep=rep1&type=pdf

On 20 January 2018 at 09:00, martin <martin.drautzburg@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.

So,
- 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:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.