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?
Share Improve this question edited Feb 9, 2019 at 4:48 user1028880 asked Feb 3, 2015 at 7:50 Alexis KingAlexis King 43.9k16 gold badges142 silver badges215 bronze badges 3- 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
Reset to default 12Behaviors 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