Why a third type Discrete?
In an ideal world, users of functional reactive programming would
only need to use the notions of
the first corresponding to value that vary in time
and the second corresponding to a stream of event ocurrences.
However, there is the problem of incremental updates.
Ideally, users would describe, say, the value of a GUI text field
Behavior and the reactive-banana implementation would figure
out how to map this onto the screen without needless redrawing.
In other words, the screen should only be updated when the behavior changes.
While this would be easy to implement in simple cases,
it may not always suit the user;
there are many different ways of implementing
But I don't know a unified theory for them, so
I have decided that the reactive-banana will give
explicit control over updates to the user
in the form of specialized data types like
and shall not attempt to bake experimental optimizations into the
To sum it up:
- You get explicit control over updates (the
- but you need to learn a third data type
Discrete, which almost duplicates the
- Even though the type
Behavioris more fundamental, you will probably use
Discrete is not a new primitive type,
but built from exising types and combinators;
you are encouraged to look at the source code.
If you are an FRP implementor, I encourage you to find a better solution. But if you are a user, you may want to accept the trade-off for now.
Discrete time-varying values
Behavior, the type
Discrete denotes a value that varies in time.
it also provides a stream of events that indicate when the value has changed.
In other words, we can now observe updates.
Event that records when the value changes. Simultaneous events may be pruned for efficiency reasons.
Behavior corresponding to the value. It is always true that
value x = stepper (initial x) (changes x)
Construct a discrete time-varying value from an initial value and a stream of new values.
Accumulate a stream of events into a discrete time-varying value.