how should variables in interactive expressions work?

[JeffBezanson]

If we support arbitrary expressions at the julia prompt within the debugger, then they can have their own local variables, including compiler-inserted temporary vars. Currently expressions share an environment with the debugged function:

julia> @enter gcd(100,25)
16  function gcd{T<:Union{Int64,UInt64,Int128,UInt128}}(a::T, b::T)
17      a == 0 && return abs(b)
18      b == 0 && return abs(a)
19      za = trailing_zeros(a)

About to run: Base.==
1|julia > foo = 42
42

1|debug > bt
[1] gcd{T<:Union{Int128,Int64,UInt128,UInt64}}(a::T, b::T) at intfuncs.jl:17
  | #self#::Base.#gcd = gcd
  | za = <undefined>
  | k = <undefined>
  | zb = <undefined>
  | T::DataType = Int64
  | u = <undefined>
  | foo::Int64 = 42

Here I was able to add a new variable to the local scope. This might be a feature, but we don't necessarily want this for all variables introduced by the expression, e.g. compiler-inserted vars, and let-bound vars. It's also more difficult to support with the new IR.

Instead, we could give an interactive expression its whole own environment, initialized by starting the code we generate with var = val for each local of the debugged function. Then we run it, and copy certain variables back to the debugged function's environment afterwards.

[Keno]

Probably makes sense to structure it that way, esp if you want it to work for native frames as well.