You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The type of the bidirectional reactimate would be Event (IO a) -> MomentIO (Event a). Whenever the input event occurs, the output event is fired. Unlike execute this would not be subject to garbage collection, and unlike mapEventIO the input and output events would be simultaneous. The reason it is called bidirectional is that not only does the event tell the IO action when to be preformed, but also allows the IO action to send a value back to the event network. There would also be a version of the type Event (Future (IO a)) -> MomentIO (Event (Future a)).
The type of bidirectional fromAddHandler would be (a -> Moment (b, c)) -> MomentIO (Event b, a -> IO c). When the IO action is preformed, its argument is used to observe the moment, which then produces the IO action's return value and fires the event. The observing of the moment and the firing of the event are simultaneous. The reason it is called bidirectional is that not only can the IO action tell the event when to fire, but also allows the event network to send a value back to the IO monad. A function of the type Behavior (a -> b) -> MomentIO (a -> IO b) that allows IO to use functions in behaviors could be derived from this, for example. There would also be a version of the type (a -> Moment (b, Future c) -> MomentIO (Event b, a -> IO c).
The text was updated successfully, but these errors were encountered:
Also, it is currently possible to write combinators like this using MVars, but might thread lock if you do it in the wrong order. By including it in the library, the users do not need to reinvent the wheel each time (and could perhaps be made more efficient).
The type of the bidirectional reactimate would be
Event (IO a) -> MomentIO (Event a)
. Whenever the input event occurs, the output event is fired. Unlikeexecute
this would not be subject to garbage collection, and unlikemapEventIO
the input and output events would be simultaneous. The reason it is called bidirectional is that not only does the event tell the IO action when to be preformed, but also allows the IO action to send a value back to the event network. There would also be a version of the typeEvent (Future (IO a)) -> MomentIO (Event (Future a))
.The type of bidirectional fromAddHandler would be
(a -> Moment (b, c)) -> MomentIO (Event b, a -> IO c)
. When the IO action is preformed, its argument is used to observe the moment, which then produces the IO action's return value and fires the event. The observing of the moment and the firing of the event are simultaneous. The reason it is called bidirectional is that not only can the IO action tell the event when to fire, but also allows the event network to send a value back to the IO monad. A function of the typeBehavior (a -> b) -> MomentIO (a -> IO b)
that allows IO to use functions in behaviors could be derived from this, for example. There would also be a version of the type(a -> Moment (b, Future c) -> MomentIO (Event b, a -> IO c)
.The text was updated successfully, but these errors were encountered: