Feature Request: Static Variables

[JaredCrean2]

As I have been programming in Julia, I have run into a situation where I want to use a temporary (usually an array) for use every time a function, but don't want to allocate a new one every time. In C, this would be easily done using a static variable. In Julia, something similar could be accomplished using global variables, but if the type of the static variable depends on the type of the function arguments, this causes type instability.

So, the request is for static variables where each compiled method of the function has its own variable, whose type is determined by type inference.

[johnmyleswhite]

I imagine the official way to do this is with closures, although that currently incurs a performance penalty if you're not careful.

That said, I have sometimes found myself wanting this feature, even if it might be redundant with other existing features.

[KristofferC]

This would remove a lot of my global consts sitting just above the method definition.

[vtjnash]

macro static(var::Symbol, init)
  eval(current_module(), :($var = $init))
  var = esc(var)
  quote
    global $var
    $var
  end
end

[carnaval]

don't listen to Jameson

[JaredCrean2]

Does that solve the type instability problem if several version of the function are compiled?

[vtjnash]

don't listen to Jameson

haha. good advice (as Oscar points out, I didn't every mark it const, gensym, or type-assert)

whether a function is compiled is orthogonal to its type signature.

[JaredCrean2]

What I meant (and didn't say very well), was what happens if the macro is run twice with the same arguments. For example:

function do_work(val::Number)
  @static(:work_vec, Array(typeof(val), 50) )
  ... do calculation here...
end

do_work(1)
do_work(1.0)

[StefanKarpinski]

Can be done pretty easily with generated functions:

@generated f(x) = quote
    a = $(Array{x}(2))
    a[2] = rand(typeof(x))
    a[1] = x
    return a
end

Here a is allocated when a method for a particular type of x is generated and then the same array is used whenever that method is called:

julia> a = f(1)
2-element Array{Int64,1}:
                    1
 -6333601391516269775

julia> b = f(2)
2-element Array{Int64,1}:
                    2
 -5064160828035242615

julia> c = f(1.5)
2-element Array{Float64,1}:
 1.5
 0.596989

julia> d = f(2.5)
2-element Array{Float64,1}:
 2.5
 0.339789

julia> a === b
true

julia> c === d
true

julia> a === c
false

Given that it's so easy to simulate, it seems like adding a specific feature isn't warranted.

[StefanKarpinski]

You can do the same thing with just eval, without generated functions if you only need a single static variable that doesn't depend on the method signature:

@eval function f(x)
    a = $(Array{Float64}(2))
    a[2] = rand()
    a[1] = x
    return a
end

This allocates a single shared array:

julia> a = f(1)
2-element Array{Float64,1}:
 1.0
 0.401537

julia> b = f(2)
2-element Array{Float64,1}:
 2.0
 0.392203

julia> c = f(3.5)
2-element Array{Float64,1}:
 3.5
 0.229555

julia> a === b === c
true

Given that this is fairly common, and differs significantly in exact implementation depending on what parts of a method signature the type of the object to be statically allocated depends on, perhaps it would make sense to have a language feature for it.

[JaredCrean2]

Works for me, although it does make the language a bit less approachable if you have to get into generated functions to do something that is both conceptually simple and easy to do in C

[StefanKarpinski]

C doesn't have parametric methods so it's not really an apples to apples comparison.

[JaredCrean2]

Fair point.

I'm ready to close the issue if you are.

[StefanKarpinski]

There may be enough here to warrant a feature – the trick would be to make the static value specific to precisely the parts of the methods signature that it depends on and not the others. Let's see what some other people think (@JeffBezanson and @Keno are traveling, but may well have opinions).

[Keno]

One thing you can do is use a let block and define the generic function inside. But yeah something that is different for every specialization is both conceptually and technically tricky.

[StefanKarpinski]

Well, the @generated example shows that it could be a fairly straightforward syntactic translation given that we've already solved a harder problem. So if the static allocation is per full method signature, we can do this already. The question is if you want to allow making it specific to some subset (possibly empty) of the type parameters of a method and how to express that (implicitly, explicitly).