# Discussion: Context Dispatch - yes? no? questions? answers?

**URL:** <https://discourse.julialang.org/t/discussion-context-dispatch-yes-no-questions-answers/24194>\
**Category:** Internals & Design\
**Created:** [May 14, 2019, 6:04am UTC](https://discourse.julialang.org/t/discussion-context-dispatch-yes-no-questions-answers/24194 "2019-05-14T06:04:01Z")\
**Posts on this page:** 1\
**Showing post:** 10

<div class="post-metadata">

**Author:** ![StefanKarpinski](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stefankarpinski/32/24_2.png) [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)\
**Post date:** [May 16, 2019, 4:25am UTC](https://discourse.julialang.org/t/discussion-context-dispatch-yes-no-questions-answers/24194/10 "2019-05-16T04:25:18Z")

</div>

> [@Proposal for SharedFunctions.jl package for optional dependency management](https://discourse.julialang.org/t/proposal-for-sharedfunctions-jl-package-for-optional-dependency-management/23526/66):
>
> **The building blocks:**
> 
> - A Context is a set of modules.
> - The Context of module M is the set of all modules that module M depends upon.
> - Extension: The method table for a Context consists only from methods belonging to modules in the Context
> - Propagation: the context is propagated recursively down the AST, and is narrowed if proven that it will resolve the call just as specific as the wider context
> 
> […]
> 
> so for your toy example, calling function B.f from the context of module C uses modules Base, A and B for its method table so there is no problem.

This seems like it requires a new version of `sort!` to be compiled not only for each type signature (roughly what we currently do), but also for each type signature and for each calling context since the method tables of all functions that are called are different in different contexts. This seems like it would massively increase the amount of compilation required, not decrease it.

> [@Proposal for SharedFunctions.jl package for optional dependency management](https://discourse.julialang.org/t/proposal-for-sharedfunctions-jl-package-for-optional-dependency-management/23526/66):
>
> Your example with Context Dispatch and automatic merging of exported names would look like:
> 
> ```julia
> module Base
> sort!(x,y) = isless(x,y)
> isless(x,y) = ErrorException("unimplemented")
> export isless,sort!
> end
> 
> module A
> struct T end
> isless(x::T,y::T) = true
> export isless
> end
> 
> module B
> using Base
> f(x,y) = sort!(x,y)
> end
> 
> module C
> using Base, A, B
>     
> g() = B.f(A.T(),A.T())
> end
> 
> ```
> 
> In the context of module C, the functions Base.isless and A.isless got merged.

What if module `A` instead defined

```julia
isless(x, y) = "surprise!"

```

This seems like it would cause `sort!` to fail with a method error even though the two `isless` functions are not the same generic function and Base is not trying to call the one that `A` defines or exports.

---

_[View the full topic](https://discourse.julialang.org/t/discussion-context-dispatch-yes-no-questions-answers/24194)._