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?

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?

• javascript
• haskell
• functional-programming
• reactive-programming
• monads

• 1 Arrow is more abstract concept related to FRP you should look it first and you see than monadic approach is less preferable haskell/arrows wiki.haskell/Arrows-based_Functional_Reactive_Programming also "Arrows, Robots, and Functional Reactive Programming" haskell.cs.yale.edu/?post_type=publication&p=175 – sigrlami Commented Feb 3, 2015 at 8:03
• @Sigrlami I admit I haven't yet taken the time to understand arrows, but thanks for the links. I'll look into those. – Alexis King Commented Feb 3, 2015 at 8:11
• in javascript, wouldn't a very simplistic definition of frp be that you treat all your data as streams? There is definitely a stream monad so isnt frp just programming with a specific (very powerful) monad? – Alfred Young Commented Jul 9, 2019 at 5:58

1 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