In a previous SO question (Is it possible?: Behavior t [Behavior t a] -> Behavior t [a]) we were analyzing the existence of a Behavior
join
(to use reactive-banana
terms).
Behavior t (Behavior t a) -> Behavior t a
Implemented in the semantic model as follows
type Behavior t a = t -> a
behaviorNow :: Behavior t (Behavior t a) -> Behavior t a
behaviorNow f t = f t t
While implementing this directly would be unfortunate since we could produce a Behavior
Monad
using const
and behaviorNow
, if and how does behaviorNow
violate the semantics of FRP?
I'd love to hear answers using the terminology of any other FRP system along with comparisons if meaningful.
In a poll based FRP system, any behavior has a meaningful
join
join bb
is the sample of theb
obtained by samplingbb
In push based FRP, any behavior that is a step function composed with other step functions has a meaningful
>>=
andjoin
. Pushing values through>>=
can be described in imperative terms:Providing a
Monad
instance may be slightly undesirable because it is likely to be chosen by preference by library users, even if it is less efficient. For example, the code in this unrelated answer performs more work when a computation was built with>>=
than if it had been equivalently built with<*>
.Conal Elliott described in declarative terms a
join
for simultaneously pushing and polling values for behaviors built from step functions:where
Future
is the type for a value we haven't seen yet,_+_
is the first of the twoFuture
possibilities to occur, and<$>
is infixfmap
onFuture
s. [1]If we don't provide any other means of creating behaviors than
then every behavior is a step function and we can use this or a similar
Monad
instance for behaviors.Difficulties only arise when we want to have behaviors that are continuous or are a function of some time other than when an event occurred. Consider if we had the following
which is the behavior that tracks the current time. A
Monad
instance for polling the system would still be the same, but we can no longer push changes through the system reliably. What happens when we make something as simple astime >>= \x -> if am x then return 0 else return 1
(wheream t
is true for times in the morning)? Neither our definition of>>=
above nor Elliot'sjoin
can admit the optimization of knowing when the time changes; it changes continuously. The best we could do to>>=
is something like:>>=
For the
join
form, we would be reduced to doing something similar, and simply record the AST in the instance that the outer behavior in ajoin
isn't a step function.Additionally, anything built using this as an input could change at noon and midnight, whether or not any other event was raised. It would taint everything from that point on with the inability to reliably push events.
From an implementation point of view, our best option would seem to be to continuously poll
time
, and replace anywhere it was used with a stepper built from the polling events. This wouldn't update values between events, so now users of our library can't reliably poll values.Our best choice for an implementation would be to keep an abstract syntax tree of what happened with arbitrary behaviors like these and provide no means to generate events from behaviors. Then behaviors can be polled, but no updates will ever be pushed for them. In that case, we might as well leave it out of the library, and let the user pass around ASTs (which they can get for
Free
), and let the user evaluate the entire AST every time it's polled. We can't optimize it any more for the library user, since any value like this can change continuously.There is one final option, but it involves introducing quite a bit of complexity. Introduce the notion of predictability for properties of continuously varying values and computations of continuously varying values. This would allow us to provide a Monad interface for a larger subset of time-varying behaviors, but not for all of them. This complexity is already desirable in other parts of programs, but I don't know of any libraries outside symbolic math which attempt to address this.