Earlier quoted context omitted.
Incremental. I think the problem is this: you have an input that you want to change a bunch of times input = ...; input += d1; input += d2; input += d3; and you have some output that depends on the input. Whenever the input changes, the output needs to be recomputed, like this input = ...; output = f(input); input += d1; output = f(input); input += d2; output = f(input); input += d3; output = f(input); The idea here…
How would writing f using combinators yield the ability to derive g?
For example, consider a map combinator. The output diff is just the input diff with a function applied to the data. More formally, for every incoming (data, time, diff) triple, an output triple (f(data), time, diff) is produced.
For a filter combinator, the output is (data, time, diff) if f(data) is true, or (data, time, 0) if f(data) is false.
A computation that wants to filter and map some data then just requires piping together these operators.
Things get interesting when you want to aggregate and join data, but Frank’s blog posts and documentation explain how you build that in a dataflow system far better than I can here.