# MultiFunctions: Context dispatch and binary cache

**URL:** https://discourse.julialang.org/t/multifunctions-context-dispatch-and-binary-cache/11565
**Category:** Internals & Design
**Tags:** proposal, scope
**Created:** [June 10, 2018, 12:12pm UTC](https://discourse.julialang.org/t/multifunctions-context-dispatch-and-binary-cache/11565 "2018-06-10T12:12:54Z")
**Posts on this page:** 1
**Showing post:** 7

<div class="post-metadata">

### Author: ![TsurHerman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tsurherman/32/1234_2.png) [@TsurHerman](https://discourse.julialang.org/u/TsurHerman)
#### Post date: [June 11, 2018, 6:39am UTC](https://discourse.julialang.org/t/multifunctions-context-dispatch-and-binary-cache/11565/7 "2018-06-11T06:39:34Z")

</div>

> [@jameson](#):
>
> This absolutely is legal to do for _all_ functions, without exception. The `sys.so` image proves that, since it contains a wide variety of code of all sorts, and most of that code is not pure.

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:

```julia

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.

> [@"Meaning", type-piracy, and method merging](https://discourse.julialang.org/t/meaning-type-piracy-and-method-merging/11003/51):
>
> > I think doing semantically clever things is very hard, because a persistent cache needs to store different versions of foo(x::Int) depending on how dependencies like Base.:+ changed, in a possibly load-order dependent way, different sessions and package versions (developers churn out a lot of versions in a single sesssion!).
> 
> That seems like a fairly nice summary of some of the challenges someone might encounter if they wanted to resolve [https://github.com/JuliaLang/issues/265](https://github.com/JuliaLang/issues/265) for example. But unfortunately, as you mentioned above, this “caching between sessions [is] impossible”.

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.

---

_[View the full topic](https://discourse.julialang.org/t/multifunctions-context-dispatch-and-binary-cache/11565)._