This table from the manual suggests the REPL has its own global scope. Whereas I’d thought the REPL executes in the scope of module Main, already in the table. Just a poorly worded table?
Yet after puzzling over this, what I’m trying now to convince myself of is why doesn’t the REPL have its own scope, a local scope nested in global scope Main. (i.e. why doesn’t REPL initialization loosely speaking just tell the interpreter it’s in global scope Main, local scope Repl before kicking off read-eval-print loop) I don’t believe I’m speaking of let wrapping.
An obstacle I saw mentioned is that the function eval evaluates in the global scope of the containing module, so not in this hypothetical local scope Repl. But, seriously, then why must the REPL use eval instead of an alternative new function that evaluates in the local scope it’s told to? What are the technical difficulties, if someone well acquainted may summarize?
I don’t know if this requires @jeff.bezanson to explain, as an interpreting issue, but the difficulties must be great indeed, judging by the extensive effort to create alternate scope semantics in the REPL when all it really wants is to be local scope.
Thanks in advance for the education–what am I missing?
Yes, the REPL parses the input and then evaluates it into Main. There is no REPL specific global scope.
Local scope is more restrictive than global scope. There are some things that can only be evaluated in global scope and some things (like method definitions) only become active after global scope is encountered.
Because if evalling into local scope was allowed then you couldn’t really optimize julia code.
The REPL could certainly act like a local scope; indeed SoftGlobalScope.jl is very close to that. The main discrepancy is this case:
julia> x = 0
julia> function foo()
x = 1
...
end
If this were all inside a local scope, the x = 1 inside the function would overwrite the outer x. That’s not what you usually want in the REPL, since then you can’t copy and paste function definitions from elsewhere. But, if you were debugging a function with inner functions by copying it line-by-line, then it would be what you’d want. Having a REPL mode to enable that would seem reasonable to me.
But as Kristoffer said, the REPL can’t actually be a local scope. The defining feature of a local scope is that the system can see every use of its variables before execution begins. That is directly at odds with a REPL, where each input has to be executed on its own.
Maybe you could have a command line option or environment variable for it. One issue with making that optional is that now you also have to specify what kind of REPL mode you are using when you share some REPL code snippets in discussion posts, since behavior would depend on REPL mode.
One solution to this would be to change the name of the REPL mode from julia> to global> maybe?
