What sys.so proves is that it is possible (although a bit painstakingly) to save a binary state of the runtime. However this binary sate is baked into the runtime in a way that does not respect the language rules…
I will explain what I mean:
module M
f(x::Float64,y::Float64) = x+y
end
M.f(1.0,2.0) # 3.0
module N
import Base.+
(+)(x::Float64,y::Float64) = 0
end
M.f(1.0,2.0) # 0
in the following example If I were to add module M into the sysimg then calling M.f(1.0,2.0) would still produce
3.0 even after I imported module N.
So there is a difference whether code is baked into sys.so or loaded at runtime.
Edit: My bad, I just tested it again, and changes to method table are visible in the modules which are compiled
as part of the runtime,
I seriously don’t understand why you all get so jinxed when I point that out, you said it yourself in a previous post,
The way multiple dispatch works right now , a method instance is dependent on the order in which modules were
added to the runtime … even modules which are not strictly visible from the module “containing” the method instance.
Another issue is purity: I believe that the term pure , in the model I propose for multiple dispatch , can be relaxed greatly to mean any function that does not declare a new global…
Well maybe a better term would be: Eventually Pure
Since the methods which a function see does not change once the module finished loading.