FRP Fails at the Edges

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.

This entry was posted in Distributed Programming, Language Design, Modularity, Open Systems Programming. Bookmark the permalink.

3 Responses to FRP Fails at the Edges

  1. Raoul Duke says:

    I wish I knew enough to understand how FRP falls down as you say here. Might you have a pointer to another place where you’ve or somebody has talked about this? I’ll go googling…

    (I thought the standard trick for making things pure was to include timestamps, and to consider the future verboten. Eg. for the history of events, I naively again think that could be exposed as a function taking some kind of index or timestamp, which returns the history, which is kept hidden under the covers in a mutable way. (For history that seems fine, for timestamps ahead of ‘now’ of course there’s trouble.))

    • You could read the Wormholes paper, which is an incomplete attempt to solve this problem (wormholes integrate effects, but do not compose effectful systems).

      The issue here isn’t “making things pure” but rather the difficulty of integrating ‘open’ resources (e.g. databases, blackboards, web servers) that multiple independent participants or agents may observe and influence. The ‘edges’ of any useful computation model are always open (i.e. sensors, actuators, real world state) so this is a pretty important failing. Purity has problems.

  2. Raoul Duke says:

    Presumably I should re-read and keep trying to digest.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s