Propagators are a more generic substrate than logic programming, similar to arrow and monad. Logic programming can be seen as one specialization: if your cells carry logical constraints and your propagators perform unification, you get a logic programming system. But unlike Prolog, the same network could simultaneously host reactive updates, arithmetic constraints, or other inference styles. In fact, Sussman & Radul’s original work shows that when propagators are specialized for logic programming, you also get constraint programming “for free,” since both are just ways of refining partial information.

Extremely insightful. Anyone familiar with monads will know they get messy when you start feeling the need for lifts and, heaven forbid, transformers. That's when something like the propagator model begins to feel like a good option. Start with a base program (the network) and then instead of messing it up with holes for lifts and transformers, insert a propagating value and let it figure out how and where to lift things. Propagators are especially good for whole program transformations.

Indeed also in Propagator (ts implementation and original version) it has a layered datum system dedicated to handle side effects, dependency tracking system was being built upon that, the concept was inspired from monad but being much more flexible than that, also in my impl I embedded a first class no-compute value, which hints Propagator that to not propagation(I know this naming was bit arbitrary, maybe using maybe monad is better) this works well when some operation failed to succeed(like fetch element from array, or dict) but not count as an error, and i feel it was much more conceptually coherent than mapping over monad

I'm going to need to look into this...