Type annotations in global scope

[maleadt]

Is it expected behaviour that I can't type annotate variable declarations in global scope? Example:

julia> foo::Float = 0.1
foo not defined

julia> function bar()
         foo::Float = 0.1
       end

julia> bar()
0.1

[Keno]

It is expected insofar as that we are aware of the issue. Currently using global variables kills performance specifically because they are of unknown type. Type annotations on global variables are a planned feature but IIRC, there was some technical limitation (maybe @JeffBezanson can go into detail on that).

Hope that helps.

[JeffBezanson]

Planned feature.

[StefanKarpinski]

Further plan: make globals type-const by default. That is, writing

glb = x

is equivalent to this:

glb::typeof(x)
glb = x

unless there was some prior declaration of the type of glb. If you want an global that can hold different types of values, you must explicitly annotate that:

glb = 1      # not const but has to be Int
glb::Any     # can hold anything
glb::String  # can hold any kind of string

This approach will alleviate the horrific performance trap that global variables currently constitute. Most globals are actually constant and they hardly ever change type.

[stevengj]

The current workaround is to declare globals as const, but this is unsatisfactory in many situations where the value of the global may change but its type does not.

I keep running into this problem in modules, in which the module needs to do some run-time initialization and cache the results in a global, but the only way to do this without screwing the compiler seems to be to annotate every place that the global is used, which is annoying.

Please don't let this issue fall off the queue.

[dmbates]

I'm not sure if this is entirely kosher but I have found that I can declare an array as const and still change the values of elements of the array. In the CHOLMOD code all the C functions have an argument which is a pointer to this horribly long cholmod_common struct and many of the optional arguments are changed by changing values in this struct. The way this is done in the extras/suitesparse.jl file in the db/suitesparse branch is to declare a const Uint8 array of the appropriate length and change the values of some parts of this array using reinterpret.

[StefanKarpinski]

That is completely kosher – the only thing that's const is the binding. The array itself is still a mutable thing. However, we still need this stuff.

[stevengj]

A possibly related problem: you can't usefully declare type annotations with the global keyword either. e.g.

x=3
baz(y::Int) = begin
    global x::Int
    x+y
end

is accepted by the parser, but the type annotation on the global statement doesn't seem to accomplish much. If you run disassemble(baz, (Int,)), you will find that it is still nowhere near as efficient as baz(y::Int) = x::Int + y.