Hi everyone ** đź‘‹
I’ve been working on a JavaScript implementation of Sussman & Radul’s propagator model and wanted to share some progress + questions. here's the link to the repo: github.com/Semi-0/Propagator
I currently have two branches:
- A custom push-based version (works, but
ambcan get weird). (In the AMB branch) - A more f aithful scheduler-based version, closer to the original design. (but amb still acts weirdly when execution gets large)
It supports almost all of the original Scheme machinery, and I’ve been experimenting with a reactive extension so propagator networks can drive UI updates.
Lately I’ve been exploring some theory: I noticed interesting parallels between wired diagrams in category theory and propagator networks , and I’m researching how to separate representation from execution (syntax vs. scheduler). And how I can perhaps making the propagator more self-reliant as independent programming languages.
Since I’m pretty new to open-source, I’d really appreciate advice on two fronts:
- Research direction → does this “wired graph <-> propagator <-> representation/execution” connection resonate with anyone? Are there papers or projects I should look at?
- Sharing the code → what’s the best way to make an infrastructure repo like this easier for others to understand? (Docs? examples? small demos?)
Thanks in advance for any pointers
For anyone not already familiar with propagators, here’s a quick refresher:
A propagator network is a collection of small, independent agents connected by cells that hold partial information. Each agent watches its inputs and, whenever it can deduce something new, it updates other cells. Unlike ordinary functions, information can flow in many directions at once — for example, if you know two sides of a right triangle, the Pythagorean propagator can solve for the third no matter which two you provide. This makes propagators a general model for constraints, dataflow, multi-directional reactivity and incremental reasoning.
I’ve never actually worked with propagators - they’ve always been a little academic for my needs, but I am interested in them. I’ve written reactive/incremental compute systems from scratch, and there’s a little resemblance, but I’ve mostly just heard about them from seeing some talks online and reading a bit about it. I’m curious the scale of system you’ve built with propagators.
In terms of your questions - have you looked at Statemate for inspiration? It’s more specifically for reactive systems, but it has a strong separation of spec and implementation and uses diagrams.
i am primarily an artist and designer working with multi-media, so i work with propagators more frequently on creative exploration. The current prototype face scalability issues because all the intermedia value are retain in the memory, this gains expressiveness but also creates memory pressure. i think this could be solved by distinguishing between discrete and continuous cell. What draws me to propagator is how they enable language level expressiveness while the topology of graph is traceable and modifiable at run time, and all the value is inspectable. Also compound propagator reinforce composable structures naturally. Most reactive systems i encountered in production level seems to deviate from the core ideas in the FRP from first principle and original Haskell implementation of FRP around behaviour composition, like (draw (circle mouse-position)) where every behaviour is a pure function, so they maintain predictability and testability. And in Propagator because every cell is continuous value, therefore you could have similar behaviour composition.
The most promising aspect for me is how propagator might be utilized in live coding. Right now most tools for artist are imperative like Processing, or open-framework. A few advanced tool like Tidal Cycle made by Alex McLean utilizes reactive programming. But propagators might have same expressiveness with functional reactive programming while being much more generic and utilizing multi-directional linking. This could potentially enable cooperative visual audio or even more experimental cross-media uses. In live coding, this might enable something like: (to-synthesizer (take-arm-rotation (gesture-recognition webcam)) audio-out)
(bi-link circle-position (some-transform-function synthesizer))
Since you've built reactive/incremental systems, what drew you away from propagators being too academic?
also thank you for your inspiration i am reading the documents right now
What's particularly interesting is that while in reactive programming, connecting multiple reactive functions to one subject is not recommended (due to side effects, resource issues, and race conditions), in propagators this is actually encouraged for robust structure.
Cells are built to accumulate all related information, then delay the decision of what to do with that information. So you could have multiple sensor tracks feeding data from different channels with different world views into the same cell, and the dependency tracking system and contradiction handler can determine what to do with these messages - whether to combine them, defer them, or resolve conflicts, or attempt selecting them based on what might fit in a bigger picture
For anyone not already familiar with propagators, here’s a quick refresher:
A propagator network is a collection of small, independent agents connected by cells that hold partial information. Each agent watches its inputs and, whenever it can deduce something new, it updates other cells. Unlike ordinary functions, information can flow in many directions at once — for example, if you know two sides of a right triangle, the Pythagorean propagator can solve for the third no matter which two you provide. This makes propagators a general model for constraints, dataflow, multi-directional reactivity and incremental reasoning.
