Move to lazy/dynamic propagation?

[JAForbes]

While working on the store, I attempted to implement a dropRepeats util (a la flyd). It worked well enough when using an output signal, but that meant I had to have multiple distinct ticks whenever a computation depended on dropRepeats, and as each child store relied on dropRepeats, that made the ticks a lot harder to debug.

So I introduced an internal S.SKIP (a la mithril), if a computation returned this special sentinel value it would not be included in streamsToResolve, and the computation process simply exited early.

This passed my tests at the time, but turns out it doesn't actually work because computeDependents recursively collects children of the dropRepeatsStream when a parent of the dropRepeatsStream is written to. This occurs before the tick has even occurred, and we can't know whether or not to exclude the children until the dropRepeats computation evaluates this tick.

So I thought, ah you can just record if something is skipped and then as the propagation continues skip children of that skipped parent. But that doesn't work because a computation can have multiple parents, and just because 1 parent was skipped, doesn't mean another one. So we'd need to know which parent triggered the child to run, which requires the intersection of parents.get(skipped) and toRun. If the intersection of those two sets only contains skipped computations, take the child out of the loop.

Now, I think that would work, but if I go and try to implement that, I'll again probably find there's some other edge case. The thing is, we've got two mental models at play, S wants to be dynamic, dynamically determining dependencies, dynamic clean up. And I very much want to have a static list of streams to propagate, and a static list of store queries to cache. It's fundamentally contradictory.

Is it actually less cycles, and less RAM, to just embrace completely lazy propagation, would it lead to a simpler internal representation and implementation? I don't know.

All the same, if we move to a dynamic propagation, it is just the original problem (difficult to debug recursive propagation) but by design. Maybe for now, I will go back to the output stream in dropRepeats and mull on this for a while.