While drilling through Method fields, I’ve found method.source.pure flag. Does it mean there’s some analysis involved indicating if the function is pure, i.e. doesn’t modify its inputs?
There’s a really simple one in type inference which we are planing to improve.
The simplest I’ve found is to ask @jameson, but it’s easy to predict the answer: he will say “no”.
Longer version: the sense of “purity” which is being used in Julia’s internals is much stronger than the intuitive notion of purity because Julia’s method tables are stateful, so almost any computation you can do is technically impure because it depends on the state of various method tables – e.g. for the + or * functions. These can be changed and indeed often are. Since there’s no way to seal these method tables (yet), there are very few situations in which no potential future method definition could change the result of a computation – you can redefine something as basic as integer addition, after all. (I don’t recommend it because your program will crash almost immediately, but you can do it.) I’ve proposed that we start referring to this extreme sense of purity as “hyperpure” or something like that, to avoid some of the confusion this terminology has been causing.
4 Likes
Thanks for the clarification. Do I understand correctly, that even though method tables for some dependencies may change, at the moment of (pre)compilation and with concrete types their state is fully deterministic? E.g. if we compile a function:
function add(x::Int, y::Int)
return x + y
end
and we know that right now + is a normal integer addition, we can infer that this function is really pure? Isn’t it what’s happening in pure_eval_call()?