Module React

Interface

Semantics

The following notations are used to give precise meaning to the combinators. It is important to note that in these semantic descriptions the origin of time t = 0 is always fixed at the time at which the combinator creates the event or the signal and the semantics of the dependents is evaluated relative to this timeline.

We use dt to denote an infinitesimal amount of time.

Events

An event is a value with discrete occurrences over time.

The semantic function [] : 'a event -> time -> 'a option gives meaning to an event e by mapping it to a function of time [e] returning Some v whenever the event occurs with value v and None otherwise. We write [e]_t the evaluation of this semantic function at time t.

As a shortcut notation we also define []_<t : 'a event -> 'a option (resp. []_<=t) to denote the last occurrence, if any, of an event before (resp. before or at) t. More precisely :

• [e]_<t = [e]_t' with t' the greatest t' < t (resp. <=) such that [e]_t' <> None.
• [e]_<t = None if there is no such t'.

Signals

A signal is a value that varies continuously over time. In contrast to events which occur at specific point in time, a signal has a value at every point in time.

The semantic function [] : 'a signal -> time -> 'a gives meaning to a signal s by mapping it to a function of time [s] that returns its value at a given time. We write [s]_t the evaluation of this semantic function at time t.

Equality

Most signal combinators have an optional eq parameter that defaults to structural equality. eq specifies the equality function used to detect changes in the value of the resulting signal. This function is needed for the efficient update of signals and to deal correctly with signals that perform side effects.

Given an equality function on a type the combinators can be automatically specialized via a functor.

Continuity

Ultimately signal updates depend on primitives updates. Thus a signal can only approximate a real continuous signal. The accuracy of the approximation depends on the variation rate of the real signal and the primitive's update frequency.

Basics

Primitive events and signals

React doesn't define primitive events and signals, they must be created and updated by the client.

Primitive events are created with E.create. This function returns a new event and an update function that generates an occurrence for the event at the time it is called. The following code creates a primitive integer event x and generates three occurrences with value 1, 2, 3. Those occurrences are printed on stdout by the effectful event pr_x.

open React;;

let x, send_x = E.create ()
let pr_x = E.map print_int x
let () = List.iter send_x [1; 2; 3]

Primitive signals are created with S.create. This function returns a new signal and an update function that sets the signal's value at the time it is called. The following code creates an integer signal x initially set to 1 and updates it three time with values 2, 2, 3. The signal's values are printed on stdout by the effectful signal pr_x. Note that only updates that change the signal's value are printed, hence the program prints 123, not 1223. See the discussion on side effects for more details.

open React;;

let x, set_x = S.create 1
let pr_x = S.map print_int x
let () = List.iter set_x [2; 2; 3]

The clock example shows how a realtime time flow can be defined.

Update steps

The E.create and S.create functions return update functions used to generate primitive event occurences and set the value of primitive signals. Upon invocation as in the preceding section these functions immediatly create and invoke an update step. The update step automatically updates events and signals that transitively depend on the updated primitive. The dependents of a signal are updated iff the signal's value changed according to its equality function.

The update functions have an optional step argument. If they are given a concrete step value created with Step.create, then it updates the event or signal but doesn't update its dependencies. It will only do so whenever step is executed with Step.execute. This allows to make primitive event occurences and signal changes simultaneous. See next section for an example.

Simultaneous events

Update steps are made under a synchrony hypothesis : the update step takes no time, it is instantenous. Two event occurrences are simultaneous if they occur in the same update step.

In the code below w, x and y will always have simultaneous occurrences. They may have simulatenous occurences with z if send_w and send_z are used with the same update step.

let w, send_w = E.create ()
let x = E.map succ w
let y = E.map succ x
let z, send_z = E.create ()

let () =
  let () = send_w 3 (* w x y occur simultaneously, z doesn't occur *) in
  let step = Step.create () in
  send_w ~step 3;
  send_z ~step 4;
  Step.execute step (* w x z y occur simultaneously *)

The update step and thread safety

Primitives are the only mean to drive the reactive system and they are entirely under the control of the client. When the client invokes a primitive's update function without the step argument or when it invokes Step.execute on a step value, React performs an update step.

To ensure correctness in the presence of threads, update steps must be executed in a critical section. Let uset(p) be the set of events and signals that need to be updated whenever the primitive p is updated. Updating two primitives p and p' concurrently is only allowed if uset(p) and uset(p') are disjoint. Otherwise the updates must be properly serialized.

Below, concurrent, updates to x and y must be serialized (or performed on the same step if it makes sense semantically), but z can be updated concurently to both x and y.

open React;;

let x, set_x = S.create 0
let y, send_y = E.create ()
let z, set_z = S.create 0
let max_xy = S.l2 (fun x y -> if x > y then x else y) x (S.hold 0 y)
let succ_z = S.map succ z

Side effects

Effectful events and signals perform their side effect exactly once in each update step in which there is an update of at least one of the event or signal it depends on.

Remember that a signal updates in a step iff its equality function determined that the signal value changed. Signal initialization is unconditionally considered as an update.

It is important to keep references on effectful events and signals. Otherwise they may be reclaimed by the garbage collector. The following program prints only a 1.

let x, set_x = S.create 1
let () = ignore (S.map print_int x)
let () = Gc.full_major (); List.iter set_x [2; 2; 3]

Lifting

Lifting transforms a regular function to make it act on signals. The combinators S.const and S.app allow to lift functions of arbitrary arity n, but this involves the inefficient creation of n-1 intermediary closure signals. The fixed arity lifting functions are more efficient. For example :

let f x y = x mod y
let fl x y = S.app (S.app ~eq:(==) (S.const f) x) y (* inefficient *)
let fl' x y = S.l2 f x y                            (* efficient *)

Besides, some of Stdlib's functions and operators are already lifted and availables in submodules of S. They can be be opened in specific scopes. For example if you are dealing with float signals you can open S.Float.

open React
open React.S.Float

let f t = sqrt t *. sin t (* f is defined on float signals *)
...
open Stdlib (* back to Stdlib floats *)

If you are using OCaml 3.12 or later you can also use the let open construct

let open React.S.Float in
let f t = sqrt t *. sin t in (* f is defined on float signals *)
...

Mutual and self reference

Mutual and self reference among time varying values occurs naturally in programs. However a mutually recursive definition of two signals in which both need the value of the other at time t to define their value at time t has no least fixed point. To break this tight loop one signal must depend on the value the other had at time t-dt where dt is an infinitesimal delay.

The fixed point combinators E.fix and S.fix allow to refer to the value an event or signal had an infinitesimal amount of time before. These fixed point combinators act on a function f that takes as argument the infinitesimally delayed event or signal that f itself returns.

In the example below history s returns a signal whose value is the history of s as a list.

let history ?(eq = ( = )) s =
let push v = function
  | [] -> [ v ]
  | v' :: _ as l when eq v v' -> l
  | l -> v :: l
in
let define h =
  let h' = S.l2 push s h in
  h', h'
in
S.fix [] define

When a program has infinitesimally delayed values a primitive may trigger more than one update step. For example if a signal s is infinitesimally delayed, then its update in a step c will trigger a new step c' at the end of the step in which the delayed signal of s will have the value s had in c. This means that the recursion occuring between a signal (or event) and its infinitesimally delayed counterpart must be well-founded otherwise this may trigger an infinite number of update steps, like in the following examples.

let start, send_start = E.create ()
let diverge =
  let define e =
    let e' = E.select [e; start] in
    e', e'
  in
  E.fix define

let () = send_start ()        (* diverges *)

let diverge =                 (* diverges *)
  let define s =
    let s' = S.Int.succ s in
    s', s'
  in
  S.fix 0 define

For technical reasons, delayed events and signals (those given to fixing functions) are not allowed to directly depend on each other. Fixed point combinators will raise Invalid_argument if such dependencies are created. This limitation can be circumvented by mapping these values with the identity.

Strong stops

Strong stops should only be used on platforms where weak arrays have a strong semantics (i.e. JavaScript). You can safely ignore that section and the strong argument of E.stop and S.stop if that's not the case.

Whenever E.stop and S.stop is called with ~strong:true on a reactive value v, it is first stopped and then it walks over the list prods of events and signals that it depends on and unregisters itself from these ones as a dependent (something that is normally automatically done when v is garbage collected since dependents are stored in a weak array). Then for each element of prod that has no dependents anymore and is not a primitive it stops them aswell and recursively.

A stop call with ~strong:true is more involved. But it allows to prevent memory leaks when used judiciously on the leaves of the reactive system that are no longer used.

Warning. It should be noted that if direct references are kept on an intermediate event or signal of the reactive system it may suddenly stop updating if all its dependents were strongly stopped. In the example below, e1 will never occur:

let e, e_send = E.create ()
let e1 = E.map (fun x -> x + 1) e (* never occurs *)
let () =
  let e2 = E.map (fun x -> x + 1) e1 in
  E.stop ~strong:true e2

This can be side stepped by making an artificial dependency to keep the reference:

let e, e_send = E.create ()
let e1 = E.map (fun x -> x + 1) e (* may still occur *)
let e1_ref = E.map (fun x -> x) e1
let () =
  let e2 = E.map (fun x -> x + 1) e1 in
  E.stop ~strong:true e2

Examples

Clock

The following program defines a primitive event seconds holding the UNIX time and occuring on every second. An effectful event converts these occurences to local time and prints them on stdout along with an ANSI escape sequence to control the cursor position.

let pr_time t =
  let tm = Unix.localtime t in
  Printf.printf "\x1B[8D%02d:%02d:%02d%!"
    tm.Unix.tm_hour tm.Unix.tm_min tm.Unix.tm_sec

open React;;

let seconds, run =
  let e, send = E.create () in
  let run () =
    while true do send (Unix.gettimeofday ()); Unix.sleep 1 done
  in
  e, run

let printer = E.map pr_time seconds

let () = run ()