Take the 2-minute tour ×
Computer Science Stack Exchange is a question and answer site for students, researchers and practitioners of computer science. It's 100% free, no registration required.

FRP is about streaming events and behaviours through pure functions. The Actor model - at least, as implemented in Akka - is about streaming immutable messages (which can be considered to be discrete events) through potentially impure objects, called actors.

So on the surface they seem related.

What else can we say about how they related? Also, what can say about which of them might be more appropriate for different application domains?

share|improve this question

1 Answer 1

Neither actors nor FRP are about streaming. Actors don't even support external configuration of an output stream.

FRP is strongly characterized by its modeling signals and events on a linear timeline, which enables FRP behaviors to compose in a deterministic manner. Actors are strongly characterized by processing messages in non-deterministic order, and have scarcely any compositional properties (i.e. you can't treat an arrangement of two actors as a larger actor).

If you're seeking similarities, both actors and FRP have a close relationship to lambda calculus. Both can model systems responsive to human input. Both support modeling of internal (local) state.

FRP supports local state through integrals or accumulators (fold over time), while actors model supports state by allowing each actor to specify its behavior for the next message in response to the current one. This pervasive support for local state makes both FRP and Actors inadequate for live programming (or runtime upgrade of program code); it becomes too easy to lose important state.

Regarding application domains:

Actors model is well suited for open systems, where we might wish to install or maintain actors at runtime. Actors model is also weakly suited to distributed systems, as the non-deterministic ordering of messages can make a conforming implementation easier. (The reason actors are not more strongly suited to distributed systems is that ensuring a message arrives 'once and only once' is quite difficult in the face of disruption, and actors also tend to require distributed GC, which is a pain.)

FRP is well suited to closed systems that operate over time - e.g. robotic controllers, music programming, computational toys. The determinism and compositional features make FRP more convenient to work with than actors, at least in those cases where FRP can directly model a solution. Integrating FRP with effects (elegantly, without hacking the model with impurity) has proven difficult. There has been recent work on effectful FRP via 'wormholes' - effectively, unique or linear typed access to resources.

There are other models that lie somewhere between FRP and Actors.

Flow Based Programming (FBP), developed by John Paul Morrison, really does support streaming of messages.

Time Warp protocols (or the more recent work on Lightweight Time Warp (LTW)) places actors-like messages on a logical timeline to provide a more controlled and compositional notion of message passing. Time warp is often used for large parallel and distributed systems, e.g. scientific computing. The original time warp was unsuited for interactive simulatons (responsiveness to human input), and LTW is only marginally suited.

I am developing Reactive Demand Programming (RDP) which enables responsive, compositional, FRP-like manipulation and processing of signals in open and distributed systems, and eliminates local state. RDP is achieved by constraining side-effects to commutative, idempotent influence on resource state by signals over time. RDP requires rethinking of resource and state models.

share|improve this answer
    
One thing I'm not happy with about FRP is that mapping a function over an event takes a finite amount of time, yet FRP will consider the resulting event to have happened at the same time as the original event. This can lead FRP's internal notion of time to get out of step with wall time, and in particular could cause events to be wrongly ordered with respect to wall time. I also don't like the fiction that event B can happen after event A, but at the same internally-recorded time as event A. –  Robin Green Jan 19 '13 at 18:39
    
@RobinGreen The ability to model 'instantaneous' progression or transformation of events is quite useful. Developers are free to compensate by modeling delay either up-stream or down-stream. With dependent or linear types, one could develop a notion of time-safety (real-time properties; allocation of latency as a resource) for FRP systems that would be difficult to model in atemporal systems. –  dmbarbour Jan 19 '13 at 20:12
    
@RobinGreen - regarding "the fiction that event B can happen after event A, but at the same recorded time", the notion of events occuring in instantaneous or transcendental time (lim(x->0+)(T+x)) is one of the universal fallacies of the 'event' abstraction. The ordering of events when duplicating, splitting, and merging event streams becomes arbitrary, inconsistent, easily loses temporal information. (cf. Why Not Events) –  dmbarbour Jan 19 '13 at 20:46

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.