# Julep: Taking multiple dispatch,export,import,binary compilation seriously

**URL:** https://discourse.julialang.org/t/julep-taking-multiple-dispatch-export-import-binary-compilation-seriously/10882
**Category:** Internals & Design
**Tags:** namespaces
**Created:** [May 14, 2018, 9:58am UTC](https://discourse.julialang.org/t/julep-taking-multiple-dispatch-export-import-binary-compilation-seriously/10882 "2018-05-14T09:58:33Z")
**Posts on this page:** 1
**Showing post:** 64

<div class="post-metadata">

### Author: ![jeff.bezanson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jeff.bezanson/32/48_2.png) [@jeff.bezanson](https://discourse.julialang.org/u/jeff.bezanson)
#### Post date: [May 16, 2018, 4:19pm UTC](https://discourse.julialang.org/t/julep-taking-multiple-dispatch-export-import-binary-compilation-seriously/10882/64 "2018-05-16T16:19:15Z")

</div>

> [@TsurHerman](#):
>
> Resolving dispatch can be defined recursively upwards in the AST (toward the caller) as follows:  
> if `func` is not an exported function it is resolved in its Module (according to B).  
> If it is an exported function it is resolved in its module ,and in its calling function scope

If I understand correctly, you’re proposing looking at the call stack and using the module of the calling code. If so, mentioning the “AST” here is incorrect, as the call stack is a dynamic property, not a static/syntactic property. You cannot determine the caller of a function by looking at ASTs.

This is closely related to the notion of “dynamic scope” (as opposed to lexical scope), where variables are looked up in calling scopes. A general problem with such approaches is that they make it hard to reason about code. If I write

```julia
f() = sum([1,2,3])

```

in my package, I intend for `f()` to return `6`. In your proposal, unless I misunderstand it, I have no idea what `f` does. If it’s called from a package that defines `sum(x) = 42`, or `a+b = 42`, then `f()` will return `42`. Yes, currently it’s possible to overwrite `Base.sum` or `+` of integers, but we discourage that and print a warning if you do it. But in your proposal it would just be the correct behavior to let another package replace the `sum` or `+` you intended to call.

This proposal also exposes implementation details. In the example in your second post, `M` needs to add `using StaticArrays` _because N uses static arrays_. That means if N decides to change its implementation to use StaticArrays, that breaks all of its users. All of its users need to add `using StaticArrays` in order to work again. I believe that is unacceptably non-modular and makes this proposal unworkable.

---

_[View the full topic](https://discourse.julialang.org/t/julep-taking-multiple-dispatch-export-import-binary-compilation-seriously/10882)._