[HN Gopher] Scoped Propagators
___________________________________________________________________
Scoped Propagators
Author : cdata
Score : 139 points
Date : 2024-07-09 13:54 UTC (1 days ago)
(HTM) web link (www.orionreed.com)
(TXT) w3m dump (www.orionreed.com)
| noelwelsh wrote:
| 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.
| aag wrote:
| 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
| orionreed wrote:
| Would love to know which videos are broken and any other
| details so I can try and fix that!
| jedharris wrote:
| None of the MP4 videos play in Firefox. The MOV videos play
| fine.
|
| All the videos play in Safari. I have not tried Chrome.
| orionreed wrote:
| 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...
| mjcohen wrote:
| The same thing seems to apply for Zoom background videos.
| Kikawala wrote:
| 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
| SrslyJosh wrote:
| None of the videos played for me in Safari 16. =(
| davexunit wrote:
| 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.
| Yen wrote:
| As a workaround in firefox, I was able to right-click, "save
| video as", and open in VLC.
| davexunit wrote:
| > 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.
| themk wrote:
| Every FRP system I've used allows cycles.
| davexunit wrote:
| Such as?
| blixt wrote:
| 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.
| graypegg wrote:
| 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.
| chatmasta wrote:
| 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)
| CyberDildonics wrote:
| It remind you of dataflow programming because it's literally
| the same thing.
| thechao wrote:
| 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.
| davexunit wrote:
| 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
| CyberDildonics wrote:
| Why would it be good when a node is data, since the data is
| always changing and the function would stay the same?
| graypegg wrote:
| 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.)
| CyberDildonics wrote:
| So you're talking about a spreadsheet but without the
| organization of having cells in a grid?
| low_tech_punk wrote:
| 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
| GrantMoyer wrote:
| As written, a "scope" is a function, s: G2 - 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:
| G2 x A x 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 x A x 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 x B)2 - None + T or even just A2 - None + T, so that events
| are limited to propagating along chains of edges.
| MurrayHurps wrote:
| 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.
| omneity wrote:
| 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)
| jiggawatts wrote:
| 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.
| hosh wrote:
| 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
| fiddlerwoaroof wrote:
| This seems like delimited continuations to me
| donpark wrote:
| Related repos:
|
| https://github.com/OrionReed/scoped-propagators
|
| https://github.com/dennishansen/holograph
| zoogeny wrote:
| 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.
___________________________________________________________________
(page generated 2024-07-10 23:01 UTC)