Functional Reactive Programming (FRP) fails for composition between open systems. For example:
- We can model a web-server as an FRP expression that transforms input connection events and state to output connection events and state updates.
- We can model a client as an FRP expression that takes UI and network events and generates UI output and network events.
- However, the client cannot treat a service as an FRP signal or event transformer
A client application is not aware of other clients. FRP is pure, thus a stateful service shared by multiple clients will never be modeled within those clients as an FRP expression. Same holds for sensors, actuators, and foreign services. Clients and servers do not compose without escaping the FRP paradigm.
A second difficulty for FRP is modeling startup and shutdown – edges in the program life cycle. In FRP, we may model a program as depending on its past. But we can’t get obtain history of mouse or keyboard events. So FRP programs become much less declarative, with behavior dependent on startup time.
FRP’s weak composition with external systems creates pressure for ‘monolithic’ applications.
Reactive Demand Programming (RDP) resolves both of these composition issues, and hopefully will achieve fine-grained service composition.