Can functional reactive programming (FRP) be expressed using monads?

Question

I've been reading up on Functional Reactive Programming, and though I have not used monads extensively in any language, I can't help but see them everywhere in the FRP design.

This question's answers have some fantastic descriptions of what functional reactive programming is, and I won't attempt to replicate that here. Basically, FRP creates relationships between values that change over time.

So can't this be represented monadically? Encapsulate the code that requires the values that are modified over time in a monad, call it Signal, then use those signals like so (using Haskell do-notation for simplicity).

do
  mx <- mouseX
  my <- mouseY
  wave <- currentTime >>= liftM sin
  -- do some stuff with these values

Or is there more to FRP than I'm understanding? Are there paradigms that prevent using such a simple representation using monads? Or is this a valid (if perhaps simplified) understanding of how FRP works?

Answer 1

Behaviors could be given monad operations. After all Behavior a is semantically Time -> a, which is Reader Time.

Also Events which are semantically [(Time, a)] could be given at least Applicative instance which would resemble ZipList structure.

Yet, even these are theoretically possible and elegant, in practice they are hard to implement. You could check "Controlling Time and Space: understanding the many formulations of FRP" by Evan Czaplicki for more information.

For example sodium have kind of monadic bind for Behaviors:

switch :: Behavior (Behavior a) -> Reactive (Behavior a)

but instead of working in the pure category, we work in Kleisli category of Reactive monad. Thus we can do a bit more.

One exercise which highlights the difficulties, is to try to implement ArrowApply for Automaton. SO provided spoiler