Scoped Propagators | Hacker News Reader

Scoped Propagators

orionreed.com

164 pointscdata31 comments

Interesting concept! It does remind me of the observables somewhat, where nodes are functions, which accept data coming in from events, which it transforms, and then chooses to emit new values or not.

This flips that, so nodes are data, which accept functions from events, it applies that function to itself, then decides to propagate that event onwards or not.

I like it! That model works really well for this sort of visual programming demoed in the infinite canvas stuff.

I only glanced at the article, but it also reminds me of Dataflow programming, incrementally updated materialized views, etc. (all the same concept at the end of the day, and yes, very similar to observables)

It remind you of dataflow programming because it's literally the same thing.

Specifically, the application of dataflow to GUIs, which was well-researched at Adobe by Sean Parent, Mat Marcus, et al in the early 2000s called the "Adam" and "Eve" languages. There's more work at TAMU & University of Turku (by Jaakko Jarvi) under the name "Espresso", or something like that.

Basically, the "scopes" become constraints, and they use a hierarchical constraint solver to propagate state changes to the GUI elements, real-time, using a declarative dataflow programming model.

As Gerald Sussman says in "We really don't know how to compute!":

> It's not dataflow! It's closely related, but it's not.

https://youtu.be/HB5TrK7A4pI?t=2071

Why would it be good when a node is data, since the data is always changing and the function would stay the same?

    the Scoped Propagator model is based on two key insights:
    1. by representing computation as mappings between nodes along edges, you do not need to know at design-time what node types exist.
    2. by scoping the propagation to events, you can augment nodes with interactive behaviour suitable for the environment in which SPs have been embedded.

It's pretty specific to UI similar to the examples, but in terms of these big infinite canvas UIs, you have a whole bunch of objects you need to make dependant on each other, but who ALSO hold their current state statically. Subtly different from a spreadsheet, where Excel for example treats functions (=$A$2) differently from a single value (4). Functions are always derived, where as single values don't rely on anything.

Like a sticky note on a canvas, should always be available to type into. But maybe we also want something else to change it's value when it changes. (key insights #2, this is for infinite canvases)

Rather than building some big god-object that stores all "root" state for the static value of things, and transforming that thru a big tree of functions you need to keep maintained, you could reverse it:

Each node only knows it's own state, but it's peers give it instructions about how to update itself to meet their business rules, for just that pairing.

The result is the same, it's a big web of functions, but now you don't have to make the distinction between "derived" state or "base" state. It's always static state, and things are just updated adhoc by these events that describe the changes without explaining "why" the "to" node has to apply them. (key insights #1, you do not need to know at design-time what node types exist.)

So you're talking about a spreadsheet but without the organization of having cells in a grid?

Some of the videos are broken for me (using Firefox). Otherwise looks pretty neat.

Compared to FRP it is perhaps a bit more declarative in the definition of scopes, but otherwise seems equivalent. I'm interested in more details on this. I'm also a bit confused by

> This model has not yet been formalised, and while the propagators themselves can be simply expressed as a function ... I have not yet found an appropriate way to express scopes and the relationship between the two.

This seems straightforward to me (e.g. a scope could be a set of types, where each distinct event has a distinct type) so I think I'm missing something here.

All but two of the videos are broken for me on both Chrome and Firefox. I would love to see the rest!

I encourage people to read the original Propagator Networks paper by Alexey Radul (advisor: Prof. Gerald Sussman of SICP) referenced in the Prior Work section. It's full of fascinating ideas.

https://dspace.mit.edu/handle/1721.1/54635

Would love to know which videos are broken and any other details so I can try and fix that!

None of the MP4 videos play in Firefox. The MOV videos play fine.

All the videos play in Safari. I have not tried Chrome.

good to know! seems that I'm using encodings for those which Firefox does not support https://stackoverflow.com/questions/73855321/why-wont-mp4-vi...

The same thing seems to apply for Zoom background videos.

Firefox doesn't support H.265/HEVC.

bridging.mov and examples.mp4 are working as they are H.264/AVC, the other videos are H.265/HEVC

None of the videos played for me in Safari 16. =(

Yeah I can't see most of the videos, either. :(

I absolutely love Alexey Radul's dissertation. So interesting to see this article show up on the HN front page after I just published my own experiment with propagators yesterday: https://dthompson.us/posts/functional-reactive-user-interfac...

I need to learn more about the design decisions behind scoped propagators and why they deviate from "regular" propagators.

As a workaround in firefox, I was able to right-click, "save video as", and open in VLC.

> Compared to FRP it is perhaps a bit more declarative in the definition of scopes, but otherwise seems equivalent.

FRP systems are typically limited to acyclic graphs. The system in this article allows for cycles.

Every FRP system I've used allows cycles.

Such as?

Reminds me of Gerald Sussman's talk "We Really Don't Know How to Compute!" (2011)

https://youtu.be/HB5TrK7A4pI?si=99cUwmS_03VwLUP7&t=2038

Very cool! Good to see the shoutout to Dennis' Holograph.so work as well. I played around with that one to make some fun things:

A game of cat and mouse: https://x.com/blixt/status/1797384954172625302

An analog clock: https://x.com/blixt/status/1798393279194824952

I think tools like these, with better UX and more guard rails for the code, can really help people understand logic and systems in a much more visually intuitive way. In some aspects, these propagators work similar to Excel, which I think a lot of people already have some intuition for.

As written, a "scope" is a function, s: G² → None + T, from the current global state and the previous global state to an optional value of some type T. Meanwhile, a "propagator" is a function, p: G² × A × B → B, from the current global state, the previous global state, a source node, and a target node to a new target node, such that p(g, g', a, b) = if s(g, g') is None then b else f(s(g, g'), a, b) for some f: T × A × B → B.

For example tick(g, g') = time(g') - time(g), and change(g, g') = if node_s(g') ≠ node_s(g) then () else None where node_s(g) gets the source node of the change scope from global state g.

In practice the outputs of a scope can be computed once per state change and called an event, rather than computed on demand each time it's used, and scopes which return None don't need to be propagated. Also, I suspect it would be useful to restrict scopes to (A × B)² → None + T or even just A² → None + T, so that events are limited to propagating along chains of edges.

Wow! That's neat! There are a lot to explore beyond interactive objects.

One of the first thing that comes to mind was is about Smalltalk, and the idea that it is about the messages and not the objects.

The next thing to come in mind is about how this allows for composition of interactions. I think it can enable highly local customization that can still receive software updates from upstream. I am thinking about how one of the problems with extensible specifications (such as XMPP) eventually lead to an ecosystem where feature updates cannot propogate easily; and we might see something like that in the Fediverse

What is separating this concept from dataflow programming, perhaps with slightly different semantics and interaction patterns? (I reckon my understanding might be limited so I'm genuinely seeking enlightenment)

This kind of node/edge based programming model is one I've been interested to see applied to LLMs.

In some sense, we can see the input of an LLM as a node, the LLM itself as a function describing the edge of the graph, and the output of the LLM as a new node.

https://github.com/dennishansen/holograph

This feels very similar to how database table triggers work. You define trigger conditions, and then the trigger on table A tells table B how to update itself. The tables store only data.

This seems like delimited continuations to me

This is genius, and very well described.

Could be a meaningful bridge between “nocode” and code, avoiding what seems like a common pain point of eventual nocode limitations. I know there are other solutions in this space, but yours is very nicely done.

Please continue work on this, and yell out if you need collaborators.

Reply on news.ycombinator.com