I've been trying to image what regular reactive programming might look like. Two things come to mind:
1) We have a update graph.
2) Each node of the graph gets updated via a distructive update.
. . . So hang on 1 sec. That sounds an awful lot like what is lurking under the hood of all the current sodium implementations. Some impls call it "Node", some call it "Vertex". So sodium is a FRP implemented via a RP, but this RP is not exposed to the end user. But should it be? It seems like Vertex/Node left unchanged is capable of both push based and push/pull based implementations.
One thing I love about FP (and FRP by extension) is the ease of refactoring. I remember in a heavily imperative code base being too afraid to swap the positions of lines of code to tidy things up because of not knowing how it would effect the program as a whole. In FP/FRP this problem disappears entirely. But does so at a slight performance over the heavily imperative one.
However chuncking up imperative blocks of code in a graph like structure with ranks and all. Gives us the ability of swaping around the positions of the imperative blocks of code without changing the behaviour of the program. Our ease of refactoring starts to return, and with no performance loss (O(1) mutable maps still usable).
FRP can still be provided as a utility built on RP, because it is still very convenient. And the RP would allow end users to create additional primitives for use in FRP in a performant way. (E.g. the router from C++ impl)
This is not something I aim to work on any time soon. Its just a though.
If vertex/node were exposed to the end user I'd probably name it "Trigger" to describe its purpose.
Something like:
Trigger::new(
setup,
tearDown,
update,
triggeredByTriggerList,
keepTriggerAliveWhileThisTriggerIsAliveList
)
Long story short. The ranks ensure mutations happen in the correct order, regardless of the refactoring and layout of the code on the outside.
