Assigning functions to variables is not reactive about pluto.jl HOT 7 CLOSED

This can be fixed if we turn run_reactive! into a recursive function: at the end of one evaluation, we can check whether any globals were assigned a reactive function, and treat them accordingly. @malyvsen

from pluto.jl.

I'd rather fix that by simplifying our model: we could treat variables and functions alike. Each varfunc would have a SymbolsState which is resolved when that varfunc (turning out to be a function!) is called. This could also work for getters, if Juia had getters - this thinking can be useful when we make Pluto.py ;)
In your example, g would have its SymbolsState copied from f (or, better, just being a reference to it) - so the call to g would be correctly identified as depending on y.

from pluto.jl.

What should happen with g = rand(Bool) ? f : identity?

from pluto.jl.

Good point! Seems like the SymbolsState shouldn't be copied - each varfunc should have a set of references to SymbolStates that it inherits from - and actually, those should just be the variables that are referenced when g is assigned to, I think?
I'll modify the example a bit for clarity, let's say we have g = rand(Float64, x) < .5 ? f : h - then g should inherit from all of x, f, h. This way, we might end up doing a bit too many updates, but I'd argue that, in the reactive paradigm, g simultaneously depends on f and h because there is no knowing which of the two it'll be after a re-run. As for inheriting from x - oh well, this isn't perfect :/ But we'll never end up updating too few cells this way so it's safe, though suboptimal.
To truly solve this problem, we would need to attach things to the variables themselves, I guess.

from pluto.jl.

That sounds like a good solution! It makes sense to derive reactivity just from syntax, and not from code evaluation.
Why should g not inherit from x?

from pluto.jl.

Would also make lambda functions reactive

from pluto.jl.

This is now a testset 🐸

It also meant reversing #25, recursion among functions now needs to be contained in a single cell, using a begin ... end block. There was no way to make it work within the paradigm.

from pluto.jl.