i was reflecting on the history of javelin recently and concluded something i'd be curious to receive validation on from an outside expert

i know that broadly reactivity can be done either "push" or "pull". push (javelin) is when you propagate values when they're set; "pull" (reagent, matrix?) is when setting a value merely invalidates a cache, and it's looking-at/dereferencing the graph that causes the cascade of requisite computation

each have their tradeoffs, but there's one that i didn't realize was a tradeoff until reflecting. in the pull system, since writing/modifying is merely cache invalidation, "in-transaction" (function calls on same stack) values are consistent with respect to one another. that is, you can modify a reactive value and refer to it on the same stack and not be surprised by its value, since writing does not necessarily trigger reactive effects

i realized that in javelin we had to simulate this with our dosync construct, which is a delimited pull system of sorts. but in a full pull system you get it for free. does that overall seem not insane and/or correct?

Perhaps a quibble, but Matrix does have lazy cells, of different varieties: lazy until read once, always lazy, lazy after intially evaluating eagerly. And another quibble: observer aka watch side-effects are dispatched immediately when each property changes, tho a "deferral" mechanism exists (a) so watches can enqueue a different MX state change or (b) so actions can be deferred to an optional client handler that runs after every change to de-dup/reorder/whatever actions recorded for it by watches. Possible quibble, Reagent does IIRC eagerly dispatch view functions when ratoms change. But I get that that is "pull" for everything else. This one I do not grok, and seems important:

you can modify a reactive value and refer to it on the same stack and not be surprised by its value, since writing does not necessarily trigger reactive effects

thanks this is all great, will digest and bbl