treat globals as constant within top-level expressions when possible

[pao]

   _       _ _(_)_     |
  (_)     | (_) (_)    |  A fresh approach to technical computing
   _ _   _| |_  __ _   |
  | | | | | | |/ _` |  |  Version 0.0.0-prerelease
  | | |_| | | | (_| |  |  Commit 335d1ef401 (2012-03-04 23:47:29)
 _/ |\__'_|_|_|\__'_|  |
|__/                   |

julia> x = 5
5

julia> typeof(x)
Int64

julia> typeof([i | i = 1:5])
Array{Int64,1}

So far, so good.

julia> typeof([i | i = 1:x])
Array{Any,1}

Wat.
(with apologies to https://www.destroyallsoftware.com/talks/wat)

[JeffBezanson]

This behavior is actually expected at the moment. Since x is global, it might change anywhere so we can't assume we know its type. This is overly pessimistic, but it's hard to come up with a rule that would let us do better.

[pao]

It's type would have to be known when it is used in the listcomp, though, as it is when I call typeof(x) directly?

[nolta]

Ok, so:

julia> test(n) = [i|i=1:n]

julia> typeof(test(5))
Array{Int64,1}

Speaking of global vs function scope, i got tripped up by this one the other day:

julia> a = 3
3

julia> @eval a + 1
4

julia> function f(n)
       b = n
       @eval b + 1
       end

julia> f(3)
b not defined

Silly nolta, eval is for globals.

[StefanKarpinski]

Ah, yes. Julia's eval always evaluates in the top-level scope.

[JeffBezanson]

I tried to send the following by email but it didn't seem to work:

Yes, you and I can see that the type of x doesn't change before it's used by the comprehension, but this is hard for the compiler to reason about. It doesn't yet have knowledge about which functions modify globals. We could "localize" globals inside inputs so that only assignments in the repl input itself can modify repl global variables.

[pao]

Okay, that makes sense. Perhaps we can write up some documentation on these global effects (potential) pitfalls, then? I can add that to my to-do list. (Is there a "documentation" tag?)

[JeffBezanson]

Well, as I said, we could decide to make the repl effectively a "local" scope, and assume that its variables can't be modified elsewhere.
REPL semantics are always troublesome.

[StefanKarpinski]

One way to handle this would be to make each repl expression behave as though all globals where let-bound when evaluating the expression, thereby making them behave like locals while evaluating, and then copy the local value back to the global at the end. Effectively this is like saying that nothing else can change globals while the repl expression is running. Which seems reasonable.

[pao]

Wandering further down the listcomp rabbit hole:

julia> typeof([a | a in 1:10 ])
Array{Int64,1}

julia> a = 'a'
'a'

julia> typeof([a | a in 1:10 ])
Array{Any,1}

Without some way to descope variables (MATLAB clear, for instance) and/or Stefan's suggestion and/or creating gensyms for loop variables such as a above to keep them from getting captured, long running REPL sessions will eventually end in some kind of death by type entropy. I personally am a fan of putting "and" into the previous sentence.

[StefanKarpinski]

Leading to the type-entropy death of the universe? Grim.

[waldyrious]

Related: #964