How is the dependency graph constructed?

Posted Nov 5, 2020 13:01 UTC (Thu) by marcel.oliver (subscriber, #5441)
Parent article: An introduction to Pluto

First, thanks for the article. The hidden state problem as well as compatibility with version control are huge issues for current notebook interfaces. (In my opinion, poor compatibility with version control is the bigger one - I know there are workarounds, but getting project members to use version control is often already an uphill battle, so any additional hoops that one has to jump through are typically not practical.)

With regards to Pluto, I am still puzzled how the dependency graph is constructed. If order of cells does not matter, that would mean either that changes to a data structure in a different cell need to be done via creation of a new object, or that the dependencies would need to be declared explicitly. From the article ("Therefore one is not allowed to define a global variable in more than one cell"), it seems that it is the former. But it's not only "defining a global variable", any write access to an object would need to be confined to a single cell. So that seems far from being able to write a generic program in Pluto notebook style, or am I missing something? It would also seem to constrain what can be done in interactive exploration. Here I am not sure what the real impact would be, but it certainly requires a change of mindset compared to working in other notebook-style interfaces.

I also wonder how much conceptually depends on specific features of the Julia language, or whether it could be implemented in just the same way for other languages (Scientific Python user here...)

How is the dependency graph constructed?

Posted Nov 5, 2020 13:29 UTC (Thu) by leephillips (subscriber, #100450) [Link]

Recalculation through the dependency graph is not triggered by mutation of existing objects, so a running a cell that has a[3] = 17 will not have any effect on other cells. One is obligated to, as you say, explicitly assign to an object. This may require additional expressions in the code that would not be present in “normal” code, but those would not change the computation, but only exist to trigger recalculation through the graph. It’s kind of an awkward aspect of the dependency graph model, but easy to get around. It’s the way this type of reactivity works. When using JavaScript reactive libraries, you sometimes have to put things like a = a in your (JavaScript) code after mutating a, to force a recalculation by explicitly having the variable on the LHS of an assignment.

The computational model does not depend on Julia, and in fact is similar to Observable, a notebook for JavaScript that uses the same type of dependency graph analysis. But other aspects, especially, apparently, in the future, may depend more closely on Julia and further ways the developers find to integrate it with JavaScript to evolve the interface.

Oh, and you’re most welcome.