type 'a t
is the type of incrementals that have a value of type 'a
.
Incrementals are not covariant, i.e. we do not have +'a t
-- consider,
e.g. set_cutoff
and get_cutoff
. However, if you have types a1
and a2
where
a1
is a subtype of a2
, and a value t1 : a1 t
, then the following builds an
incremental value of type a2 t
:
let t2 : a2 t = t1 >>| fun a1 -> (a1 : a1 :> a2)
If is_const t
then t
is a constant-valued incremental. is_const (const a)
is
true.
const v
returns an incremental whose value never changes. It is the same as
return
, but reads more clearly in many situations because it serves as a nice
reminder that the incremental won't change (except possibly be invalidated).
map t1 ~f
returns an incremental t
that maintains its value as f a
, where a
is the value of t1
. map2
, map3
, ..., map9
are the generalizations to more
arguments. If you need map<N> for some N > 9, it can easily be added, but also see
array_fold
and unordered_array_fold
.
f
should not create incremental nodes but this behavior is not checked; if you
want to create incremental nodes, use bind
. The invalidation machinery that is
used with bind
is not used with map
.
bind t1 f
returns an incremental t2
that behaves like f v
, where v
is the
value of t1
. If t1
's value changes, then incremental applies f
to that new
value and t2
behaves like the resulting incremental.
bind
can be significantly more expensive than map
during stabilization, because,
when its left-hand side changes, it requires modification of the incremental DAG,
while map
simply flows values along the DAG. Thus it is preferable to use map
(and its n-ary variants above) instead of bind
unless one actually needs bind
's
power.
bind2 t1 t2 f
is:
bind (map2 t1 t2) ~f:(fun v1 v2 -> (v1, v2))
(fun (v1, v2) -> f v1 v2)
This is equivalent to bind t1 (fun v1 -> bind t2 (fun v2 -> f v1 v2))
but more
efficient due to using one bind node rather than two. The other bind<N>
functions
are generalize to more arguments.
if_ tb ~then_ ~else_
returns an incremental t
that holds the value of then_
if
tb
is true, the value of else_
if tb
is false. Note that t
only depends on
one of then_
or else_
at a time, i.e. if_ tb ~then_ ~else
is like:
bind b ~f:(fun b -> if b then then_ else else_)
which is not the same as:
map3 b then_ else_ ~f:(fun b then_ else_ -> if b then then_ else else_)
freeze ?when_ t
returns an incremental whose value is t
's value v
until the
first stabilization in which when_ v
holds, at which point the freeze node's value
becomes constant and never changes again. Calling freeze t
forces t
to be
necessary until it freezes regardless of whether the freeze node is necessary, but
not thereafter (although of course t
could remain necessary for other reasons).
The result of freeze t
, once frozen, will never be invalidated, even if t
is
invalidated, and even if the scope in which the freeze is created is invalidated.
However, prior to when_ v
becoming true, freeze t
can be invalidated.
depend_on input ~depend_on
returns an output
whose value is the same as
input
's value, such that depend_on
is necessary so long as output
is
necessary. It is like:
map2 input depend_on ~f:(fun a _ -> a)
but with a cutoff such that output
's value only changes when input
's value
changes.
array_fold ts ~init ~f
creates an incremental t
whose value is:
Array.fold ts ~init ~f:(fun ac t -> f ac (value t))
In a stabilization during which any of the ts
changes, the entire fold will be
computed once all of the ts
have been computed.
unordered_array_fold ts ~init ~f ~f_inverse
folds over the ts
. Unlike
array_fold
, the fold will be computed in time proportional to the number of ts
that change rather than the number of ts
. In a stabilization, for each t
in
ts
that changes from old_value
to new_value
, the value of the unordered-array
fold will change from b
to f (f_inverse b old_value) new_value
. The t
's that
change may take effect in any order.
If repeated changes might accumulate error, one can cause the fold to be fully
computed after every full_compute_every_n_changes
changes. If you do not supply
full_compute_every_n_changes
, then full computes will never happen after the
initial one.
opt_unordered_array_fold
is like unordered_array_fold
, except that its result is
Some
iff all its inputs are Some
.
sum ts ~zero ~add ~sub ?full_compute_every_n_changes
returns an incremental that
maintains the sum of the ts
. It uses unordered_array_fold
so that the work
required to maintain the sum is proportional to the number of ts
that change
(i.e. one sub
and one add
per change).
opt_sum
is like sum
, except that its result is Some
iff all its inputs are
Some
.
Incremental has a timing-wheel-based clock, and lets one build incremental values
that change as its time passes. One must explicitly call advance_clock
to change
incremental's clock; there is no implicit call based on the passage of time.
The alarm_precision
of the underlying timing wheel.
now t
returns the current time of incremental's clock.
advance_clock t ~to_
moves incremental's clock forward to to_
. advance_clock
raises if to_ < now t
. As with Var.set
, the effect of advance_clock
is not
seen on incremental values until the next stabilization. Unlike Var.set
, calling
advance_clock
during stabilization raises.
In certain pathological cases, advance_clock
can raise due to it detecting a
cycle in the incremental graph.
at time
returns an incremental that is Before
when now () <= time
and
After
when now () >= time + alarm_precision
.
at_intervals interval
returns an incremental whose value changes at time intervals
of the form:
Time.next_multiple ~base ~after ~interval
where base
is now ()
when at_intervals
was called and after
is the current
now ()
. As with at
, at_intervals
might fire up to alarm_precision
late.
at_intervals
raises if interval < alarm_precision
. The unit t
that
at_intervals
returns has its cutoff set to Cutoff.never
, so that although its
value is always ()
, incrementals that depend on it will refire each time it is
set. The result of at_intervals
remains alive and is updated until the left-hand
side of its defining bind changes, at which point it becomes invalid.
step_function ~init [(t1, v1); ...; (tn, vn)]
returns an incremental whose initial
value is init
and takes on the values v1
, ..., vn
in sequence taking on the
value vi
when the clock's time passes ti
. As with at
, the steps might take
effect up to alarm_precision
late.
It is possible for vi
to be skipped if time advances from t(i-1)
to some time
greater than t(i+1)
.
The times must be in nondecreasing order, i.e. step_function
raises if for some i
< j
, ti > tj
.
snapshot value_at ~at ~before
returns an incremental whose value is before
before at
and whose value is frozen to the value of value_at
during the first
stabilization after which the time passes at
. snapshot
causes value_at
to be
necessary during the first stabilization after which time passes at
even if the
snapshot
node itself is not necessary, but not thereafter (although of course
value_at
could remain necessary for other reasons). The result of snapshot
will
only be invalidated if value_at
is invalid at the moment of the snapshot.
snapshot
returns Error
if at < now ()
, because it is impossible to take the
snapshot because the time has already passed.
observe t
returns a new observer for t
. observe
raises if called during
stabilization.
By default, an observer has a finalizer that calls disallow_future_use
when the
observer is no longer referenced. One can use ~should_finalize:false
to cause the
finalizer to not be created, in which case the observer will live until
disallow_future_use
is explicitly called.
on_update t ~f
is similar to Observer.on_update_exn
, but it does not cause t
to be necessary.
stabilize ()
recomputes all incrementals that are necessary and stale. I.e. it
propagates changes from variables that have been set to the necessary incrementals
that depend on them, stopping propagation as per cutoffs.
set_cutoff t cutoff
replaces the current cutoff function for t
with cutoff
.
cutoff
will be called any time t
is recomputed, with old_value
being the value
of t
before the recomputation and new_value
being the value that just
recomputed. If cutoff ~old_value ~new_value
, then t
's value will remain as
old_value
(new_value
is discarded) and the anything depending on t
will not be
recomputed (at least not because of t
). If not (cutoff ~old_value ~new_value)
,
then t
's value will become new_value
, and all nodes depending on t
will
recomputed.
A reasonable choice for cutoff
is an equality function on 'a
.
The default cutoff for every node is phys_equal
. For example, this means that a
unit incremental
would only fire once; to disable this, use set_cutoff t
Cutoff.never
.
lazy_from_fun f
is like Lazy.from_fun f
, except that the nodes created by f
will be created in the scope in which lazy_from_fun
was called, rather than in the
scope of the piece of code that first forces the resulting lazy. Not using this
function when defining lazy values is likely to result in exceptions being thrown by
incremental. As a rule of thumb, all lazy e
that might create incremental nodes
should be replaced by lazy_from_fun (fun () -> e)
.
As usual with Lazy
, if f
raises, then that exception will be raised when calling
Lazy.force
.
memoize_fun f hashable
returns a function m
that is a memoized version of f
that will run f a
on each distinct a
that m
is applied to, memoize the result
(in a hash table), and thereafter for a
, m
will return the memoized result.
When m
is called, it uses Scope.within
to run f
in the scope that was in
effect when memoize_fun f
was called. This is essential to correctly capture the
dependence of nodes that f
creates on values that f
is closed over, which may in
turn depend on the left-hand sides of binds in the scope in effect when memoize_fun
f
was called. Furthermore, nodes that f
creates do not depend on the scope in
effect when m
is called.
memoize_fun_by_key
is a generalization that allows one to memoize over values that
contain a uniquely identifying key, but also have other data.
For debugging purposes, one can store an arbitrary Info.t
in a node. This will
be displayed as part of a node in error messages.
save_dot file
outputs to file
the DAG of all necessary nodes, in dot format.
If keep_node_creation_backtrace
, then whenever a new node is created, incremental
will call Backtrace.get
and store the result in the node. The backtrace will then
appear in subsequent error messages when the node is pretty printed.