I have a function that uses a constant parameter. The parameter never changes between function calls. For example:
function radtodeg(x)
const PI = 3.14159
return x * 180 / PI
end
Here PI is a constant that doesn’t change between function calls. Moreover, it is only used by the function (PI is a bad example in this regard), so it makes no sense to declare it as a global constant. Also, it makes no sense to have the caller pass the constant variable pre-allocated, because this is a parameter that only makes sense internally in the function.
A more complicated example could use a constant array instead of just a number. I don’t want to have to reallocate this variable every time the function is called.
In C++, you could mark such constant parameters as const static. I understand that a proposal for static variables was rejected:
I saw that. I just think it is too convoluted. Specially compared to just saying const static as in C++.
I was wondering if there was a better and also more readable way.
If verbosity is a problem, you can go back to the good ol’ eval at compile time trick, which comes with its own set of restrictions:
macro static_var(x)
anon = gensym()
fun = eval(Main, :(const $anon = $x))
:(Main.$anon)
end
function test()
secret = @static_var begin
println("Var, so static right now")
"i did it!"
end
secret
end
>Var, so static right now # println at definition time
test() # no println no more
> i did it
julia> @code_warntype test()
Variables:
#self#::#test
secret::String
Body:
begin
secret::String = Main.##270 # line 6:
return secret::String
end::String
You could come up with quite a variety of macros to do similar things depending on your taste and goals.
@sdanisch This only works with compile-time constants, right? What if my static variable is run-time constant (meaning that the value is set once and for all at run time, but may change between runs)?
Maybe that use-case is too weird and need not be considered…
I don’t think that feature request was rejected so much as deemed “not important enough to work on now”. There are ways of getting what you need and a static variable feature could be added in the future. Using a global constant here seems fine to me since a static variable is just a global constant whose name is only visible to one function.
@jtravs I’m thinking of a constant that takes more space, like an array of coefficients. I don’t think that can be inlined, and I want to make sure it is allocated only once.
If it’s an array of constants, can’t you write it without the array? Maybe a macro would make it nicer, and then you could use a1 instead of a[1] etc., and it would all inline at compilation.
@ChrisRackauckas What if it is a constant matrix? You don’t want to expand it into components a1, ... because you want to exploit matrix multiplication.
I suspect it’s not widely useful enough to have in base; but the good news is that if it doesn’t require language support, there’s no real downside to having it in a package.
The LLVM code isn’t going to be as clean as the “really static” version because you have to do pointer lookups and branches to initially set the variable. Such is the cost of being dynamic, I’m afraid.
Depends on how big it is. It may be a good idea to skip BLAS if the constant matrix is small enough. But yes, the right approach all depends on the problem, which I do not know. I was just suggesting other approaches.
Another way you might want to handle this without polluting any good names in the global namespace is to use a more specific global name, and alias it in the function. Like
I dont think it’s weird. This is how local static variables work in C. I think it would also reduce a lot of the use cases for global variables. IMHO, static local vars would be better than globals.
This reminds me of a situation I encounted the other day in which some kind of global variable would be convenient. I had an array of objects that needed a common variable. In some languages, its possible to do something like this:
mutable myStruct
global x::Int
y::Int
end
M = [myStruct() for i in 1:100]
myStruct.x = 1
The field x would be the same across all elements in M and could be updated simultaneously. The field y, on the other hand, could be unique for each element in M. Is it possible to achieve this with a variation of your code (it does not appear to work as is)?