Fix Pack.@asdf references

[ederag]

Using the Pack.@asdf example already present in tests (but only for symbol state, not ReactiveNode).

Before

julia> ex = :(Pack.@asdf);

julia> compute_reactive_node(ex).references
Set{Symbol} with 1 element:
  Symbol("Pack.@asdf")

This sometimes broke reactivity in Pluto because the :(import Pack) cell definitions were :Pack,
which does not match the Pack.@asdf in references.

With this PR

julia> compute_reactive_node(ex).references
Set{Symbol} with 1 element:
  :Pack

The Pluto tests pass with these changes (with EE dev'ed),
but please check thoroughly, as I'm very new to this stuff.

[fonsp]

Thanks for looking into this!

Indeed your example should have Pack inlcuded in the references, but Pack.@asdf should be there as well. This matches what we do for Pack.asdf(123) (except for the macrocalls field of course):

Before this PR:

Also check Path.SubPath.func(123) and compare.

[ederag]

OK, no objection to keeping it as well.
But just to check my current understanding,
the joined reference (e.g. Path.SubPath.func) is not used for reactivity, right ?

[fonsp]

Yes, it's used to find the link between

Example.func(x::MyType) = "asdf"

and

Example.func(MyType())

[ederag]

Thanks, your explanations were very interesting.
I overlooked that definitions could be added to a module from within Pluto.

But it does not seem possible for macros.

# ╔═╡ 67c2e8fe-67d3-4757-b649-5de0d82735b5
import Pluto.PlutoRunner

# ╔═╡ cd07dcd1-bc1f-43b9-bc8c-9e9893ff89f3
PlutoRunner.bar = 1  # needs an existing name in the module

# ╔═╡ b8f2a0b2-b751-46c7-b676-431c5018e4e9
macro PlutoRunner.bar(x)
	esc(x)
end

yields

syntax: invalid macro definition

So I'm not sure f74002e is adequate now,
but it does not hurt either ?

[fonsp]

Thanks, this is great!

About your example – I think we would want to make this reactive:

Package.@hello 123

# adding a new method to an existing macro
Package.@hello(x::Int64) = x + 1

But I'm pretty sure we would need some other changes in Pluto to support this. But for the correctness of ExpressionExplorer this is a nice change! And it fixes your issue, which one was it again?

[ederag]

The issue was not reported per se, just discovered while working on fonsp/Pluto.jl#3263.

By the way, the core of that Pluto issue is clear now;
need to think again, and probably write a summary to get advises for a fix.