Inconsistencies in the meaning of code, post binding-partitioning

[timholy]

I'm not sure there's really anything broken here, but I do want to document my unease about one aspect of the binding partitioning work: it seems to change our notion of the meaning of code--in the sense of "source text"--with respect to world age. Specifically, for methods

f() = 1
g() = f()
f() = 2

we declare that g's reference to f takes precedence over the specific definition of f at the time g was defined: henceforth, g() should return 2. Meaning, the source code should reflect the current world even if it was written in an older one.

However, when it comes to types, we do the opposite, with meaning being dependent on the time at which the code is written:

struct InvalidatedBinding
    x::Int
end
struct Wrapper
    ib::InvalidatedBinding
end
struct InvalidatedBinding
    x::Float64
end

julia> Wrapper(InvalidatedBinding(2.0))
ERROR: MethodError: Cannot `convert` an object of type InvalidatedBinding to an object of type @world(InvalidatedBinding, 38792:38798)
The function `convert` exists, but no method is defined for this combination of argument types.

Closest candidates are:
  @world(InvalidatedBinding, 38792:38798)(::Any)
   @ Main REPL[1]:2
  convert(::Type{T}, ::T) where T
   @ Base Base_compiler.jl:136

Stacktrace:
 [1] Wrapper(ib::InvalidatedBinding)
   @ Main ./REPL[2]:2
 [2] top-level scope
   @ REPL[4]:1

This error happens because in reality the definition of Wrapper is

struct Wrapper
    ib::@world(InvalidatedBinding, 38792)
end

But that's not visible in the source text. It's also applicable to anyone who wrote a method

getx(ib::InvalidatedBinding) = ib.x

before the change to InvalidatedBinding, because the real "meaning" of that method definition is

getx(ib::@world(InvalidatedBinding, 38792)) = ib.x

I'm uncertain about whether we can, and would want to, change this behavior. Revise has made significant strides at this in timholy/Revise.jl#894, leveraging the fact that it has a cache of the original expressions for all the types and methods and can just re-evaluate them. But Julia doesn't, so if it can be changed it would have to be by a different mechanism. But maybe it doesn't even make sense to try: if a type changes its definition entirely, one might have to manually update much of the code that uses it anyway, and Revise's attempts to naively migrate to the new definition seem to hold some potential for trouble.

A related perspective is that if we decide the current path makes sense and I just need to finish the changes to Revise, it makes Julia less "complete" without Revise. Prior to binding partitioning, the only thing you needed Revise for was to pick up changes made by your editor: you could always manually re-evaluate the method in the REPL, which would invalidate precompiled code and any later usage of those methods would reflect the new definitions. But if one changes a type definition, you're effectively "deleting" all the methods that are restricted to that type, and would have to manually re-evaluate them all. In that sense, changing a type manually leaves your system in a broken state, and without a tool like Revise to systematically redefine the entire set of dependents, you have a fairly useless system. In the long run (after JuliaLowering), I expect much of Revise's core machinery to be done at the time code is parsed by Julia, and that Revise will become a stdlib, so this may not be as much of a problem as it might otherwise be.

[StefanKarpinski]

I haven't thought that deeply about it, but that does seem inconsistent. It seems that to fix this we would need to add backedges from types to other types. Do we stop there? What if the type of a field is given by a function call? We evaluate that function call at the time of type definition, but what if the definition of the function changes? Should we reevaluate the type definition too? That would suggest not only backedges from types definitions to other types definitions, but also from functions to types. I'm not against that, just trying to think through all the full logic here.

[timholy]

Yes, a way to make types behave the same way as methods is to add more backedges. This gets a bit scary for something like Int. There's a process of scanning the system that partially substitutes for backedges. So it may just be a matter of expanding that scan.

With backedges vs scanning, the tradeoff is speed-vs-memory. It may be acceptable to tell users "if you're redefining a type, expect some delay." But perhaps not if that delay is longer than it would take to restart Julia and reload all the requisite packages & data. That seems unlikely to be a major issue, though: we have to do a full scan when we precompile, and that's much less time than LLVM consumes (re)compiling the code.

[mbauman]

I'm not as certain that this is inconsistent — the distinction is between a definition and execution, no? Ignoring the redefinition part of it, I can also just write:

g() = f()
f() = 2

Calling g will of course error until f is defined, but that doesn't matter. The same "inconsistency" applies here — I can't do the analogous definition of Wrapper before InvalidatedBinding exists.

struct Wrapper
    ib::InvalidatedBinding  # This errors because InvalidatedBinding isn't defined yet
end
struct InvalidatedBinding
    x::Float64
end

I do suppose that "fixing" this would enable #269 without the need for an incomplete forward declaration, no?

[timholy]

What's different, though, is that if I previously defined InvalidatedBinding, then defined Wrapper, and finally re-defined InvalidatedBinding, then Wrapper sort of goes away until I redefine it too. That doesn't happen with methods.

[mbauman]

I guess my question is: are the Wrapper and InvalidatedBinding struct definitions fundamentally different from:

InvalidatedBinding = @NamedTuple{x::Int}
Wrapper = @NamedTuple{ib::InvalidatedBinding}
InvalidatedBinding = @NamedTuple{x::Float64}

?

Or even a = 1; b = a; a = 2? What if I even put consts on those lines? Should Julia go back and re-define Wrapper for me? Perhaps Revise could — and Pluto would! — but I don't think Julia itself should.

In my mind, struct definitions are more akin to a naming/assignment/definition than a thunk of code.

[StefanKarpinski]

I think that Matt has a good point here: in function bodies, variables are "dereferenced" when the code runs; the values of types on fields in a type definition are evaluated when the type is defined. We don't need any of the new binding replacement stuff to demonstrate the same difference, we can just use an old fashioned mutable global:

f1() = 1
f2() = 2

f = f1

g() = f()

f = f2

versus

struct InvalidatedBinding1
    x::Int
end
struct InvalidatedBinding2
    x::Float64
end

InvalidatedBinding = InvalidatedBinding1

struct Wrapper
    ib::InvalidatedBinding
end

InvalidatedBinding = InvalidatedBinding2

[timholy]

Agreed, if you think (correctly) of types as data. But the fact that bindings consolidate different bits of data into an entity of the same name muddies the waters a bit: in foo(x::InvalidatedBinding), does InvalidatedBinding refer to the type or the binding? If you think it should refer to the binding, then you might be forgiven for thinking that method lookup should resolve that dispatch using the value of the binding in the current world age.

[timholy]

I think we need to expect that a lot of users will think about it this way: in one case, I'm changing something in the body of my function, in another case I'm changing something in the body of my type. If you know compiler internals, that is not how you think about it, but I predict that a lot of users will.

[topolarity]

To add to the library of use / corner cases, here's an example that I expect will be challenging, but arguably realistic:

# This function has many methods, some of which depend on `InvalidatedBinding`
bar(a::Int) = InvalidatedBinding()
bar(b::Float64) = ValidBinding()
bar(c::Any) = nothing

# In `foo`, it ends up on the other side of a dynamic dispatch
function foo()
    # ...
    return bar(poorly_inferred_x)
end

# Does `list = ...` re-evaluate eagerly because `InvalidatedBinding` changed, even though
# the compiler doesn't actually "know" that you depended on it? (but you might have!)
const list = [foo() for el in items]

The initializer case adds a lot of new challenges on top of the (already challenging!) type definition case IMO

If you only have a static analysis (whether it's a new syntactic one in Revise or one extending the existing machinery in Compiler), you have a really hard time deciding "Did list depend on InvalidatedBinding, so that I should re-evaluate it?" and there'll be situations like this one where you're forced to dramatically over-estimate the set of impacted globals from a binding change

The other obvious challenge here is that initializers can frequently be side-effecting and have implicit dependencies between them. Do we want to consider them safe-for-re-evaluation to begin with? As a user, I'd certainly expect that:

const list = InvalidatedBinding[ #= ... =# ]

would re-evaluate when InvalidatedBinding is re-defined, but I'd also be pretty confused when my side effects wreak havoc

[Keno]

This was a fundamental design decision. There is an evaluation time difference between the top level definition and the function body, so there is no inconsistency. The core language does not in general keep edges on definition effects. Revise can and should do that of course.