FRP and transducers don't have much to do with one another at all. Transducers involve construction of processor pipelines ("roughly", a bunch of chained flatmaps/list monad binds). FRP is an abstraction over synchronous reactive programming which hides sample rate.
Reactive Programming is thrown in there for good measure as well, but typically "reactive" applies to anything which is synchronous or asynchronous programming but usually does not abstract sampling rate at all.
The upshot is that FRP is the most uncertain today and also the most composable. Reactive Programming is mostly programming with asynchronous streams and is a little ad hoc and, ultimately, a really wide space of approaches.
Transducers are a very particular tool for constructing "container transformers" which might be used to build some small piece of a reactive programming system. Mostly likely they'll not be used in a true FRP system because they understand the notion of discrete updates which break the composability of FRP.
Comments
FRP and transducers don't have much to do with one another at all. Transducers involve construction of processor pipelines ("roughly", a bunch of chained flatmaps/list monad binds). FRP is an abstraction over synchronous reactive programming which hides sample rate.
Reactive Programming is thrown in there for good measure as well, but typically "reactive" applies to anything which is synchronous or asynchronous programming but usually does not abstract sampling rate at all.
The upshot is that FRP is the most uncertain today and also the most composable. Reactive Programming is mostly programming with asynchronous streams and is a little ad hoc and, ultimately, a really wide space of approaches.
Transducers are a very particular tool for constructing "container transformers" which might be used to build some small piece of a reactive programming system. Mostly likely they'll not be used in a true FRP system because they understand the notion of discrete updates which break the composability of FRP.