# Proposal for SharedFunctions.jl package for optional dependency management

**URL:** https://discourse.julialang.org/t/proposal-for-sharedfunctions-jl-package-for-optional-dependency-management/23526
**Category:** Internals & Design
**Created:** [April 25, 2019, 5:18pm UTC](https://discourse.julialang.org/t/proposal-for-sharedfunctions-jl-package-for-optional-dependency-management/23526 "2019-04-25T17:18:42Z")
**Posts on this page:** 1
**Showing post:** 65

<div class="post-metadata">

### Author: ![chakravala](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chakravala/32/6832_2.png) [@chakravala](https://discourse.julialang.org/u/chakravala)
#### Post date: [April 30, 2019, 3:50pm UTC](https://discourse.julialang.org/t/proposal-for-sharedfunctions-jl-package-for-optional-dependency-management/23526/65 "2019-04-30T15:50:29Z")

</div>

> [@StefanKarpinski](#):
>
> If there are other references

Another topic which we [discussed previously](https://discourse.julialang.org/t/possibility-of-local-import-statements-in-future/10611) is the notion of a `local import` statement

> [@Possibility of \`local import\` statements in future?](https://discourse.julialang.org/t/possibility-of-local-import-statements-in-future/10611/1):
>
> The problem is, any new module that is defined with `import` statements extend on a global scope before `using` it.
> 
> Therefore, it would have language applicability if the `import` statement could be handled locally, and then optionally extended to the main scope with `using` . I’ve been told it isn’t possible with Julia, but I am optimistic. It would require some kind of a table that keeps track of which method extensions are available in what scope. Saying that it is entirely impossible seems rather improbable to me.
> 
> Perhaps, having this could speed up the method-look-up in some cases, since there would be fewer extensions to search through in a given scope.
> 
> Before you try to shove this issue under the rug, consider that multiple packages that all define arithmetic operations on symbols and expressions cannot be loaded at once because of this issue. However, if `local import` where possibe, then different packages that depend on different extensions of the same methods can be used together without interference (because then scope determines the method extension selection).

This is what resulted in making the `@force import` macro in [ForceImport.jl](https://github.com/chakravala/ForceImport.jl) … however, the real source of the problem is as I had mentioned, the context-based dispatch problem:

> [@Possibility of \`local import\` statements in future?](https://discourse.julialang.org/t/possibility-of-local-import-statements-in-future/10611/4):
>
> Essentially, what I am noticing is a greater extent of context sensitive ambiguity in the Julia language. What prevents the Julia language from truly being able to have a 1-1 correspondence with mathematical vernacular is its ability to discern context sensitive ambiguities. Mathematicians are able to do this, but most programming languages, including Julia, cannot. One example of contex sensitive ambiguity is the fact that Julia cannot discern between the overloaded definitions of + by scope. …

One of my major other ideas was to have a context-sensitive dispatch with `local import` ability.

The `@force import` macro only simulates this feature by completely separating the method tables for the conflicting methods, and then using forwarded dispatching to handle `Base` dispatch.

What is being talked about here is the full solution to this problem.

---

_[View the full topic](https://discourse.julialang.org/t/proposal-for-sharedfunctions-jl-package-for-optional-dependency-management/23526)._