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
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.