# 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:** 21

<div class="post-metadata">

**Author:** ![jlperla](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jlperla/32/34332_2.png) [@jlperla](https://discourse.julialang.org/u/jlperla)\
**Post date:** [May 15, 2018, 6:55pm UTC](https://discourse.julialang.org/t/julep-taking-multiple-dispatch-export-import-binary-compilation-seriously/10882/21 "2018-05-15T18:55:44Z")

</div>

> [@ScottPJones](#):
>
> Since then, I’ve learned how to make a local definition and manually make it use the types local to the module, and otherwise fall back to the external (usually Base) definition.  
> I do wish that there had been some syntactic sugar for doing that, so now I’m looking at having macros take care of it for me, as much as possible, but I do agree with a number of the other people here, that there doesn’t need to be any real changes to the current dispatching model achieve that.

Yup. The current approach is simply unable to cope with what many people (myself included) have been asking for, which makes it clear that it is only possible in Julia v2.0. This whole thread is yet another case of the inherent issues with the current lookup methods of functions and methods with namespaces. Maybe syntactic sugar is helpful to “get by” while new namespace/lookup design approaches are thought through, but the solution should not be to have a bunch of macros to muck around with other namespaces and manually merge what should be seamless.

Something as radical as [Function name conflict: ADL / function merging?](https://discourse.julialang.org/t/function-name-conflict-adl-function-merging/10335) is the only way to fundamentally solve this (assuming that it works in Juilia). I think that we made progress there on understanding why the current design is surprising to many people from other languages, and how a using-free design was possible with argument dependent lookup.

But lets say that there is agreement with the core developers that there is a real problem and that lookup rules need to be reexamined (which I am not sure is true we have agreed on yet). Then what is the point of talking about this much pre-v2.0 design?

My answer is that if there is at least some agreement on the direction of method lookup in v2.0 (or that it should be reexamined) then it tells us what sorts of hacky macros are acceptable in the meantime. Put another way, if the end-result is that functions will always be in a global namespace - which counterintuitively ends up helping keep methods in local namespaces - then macro hacks which automatically merge methods are pretty innocuous.

---

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