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

Internals & Design
13

Assume you are actually open to criticism, every single issues I’ve brought up in Possibility of `local import` statements in future? still hold. Namely,

  1. The additional dispatch rule complexity can only work if it essentially makes it the same as the dispatch rule now, i.e. even though it may not see all the definitions on all methods, it has to see all the definitions on the methods it use.
  2. It’s solving none issue. In fact, it makes binary compilation completely useless. The toplevel module is basically always user code (or even if it is not what you mean by toplevel, having to resolve the function at this level is at least something you have to support and not something that compilation can possibly handle) so you’ll have to compile everything when the user calls it.

Just to be more concrete, I’ll copy my example over, with changes so that the implementation details are hidden,

# All modules are using all other modules that the module is aware of (either because it's the user's choise to use them together or because it's an implementation detail) so no new using/import can be added.
module IfaceDefAndUse
# This module cannot be aware of any other modules
export g, f
function g end
f(a, b) = g(a, b)
end

module WrapperOfIfaceUse
using IfaceDefAndUse
export k
k(a, b) = IfaceDefAndUse.f(a, b)
end

module IfaceImpl
using IfaceDefAndUse
export T, f
struct T end
IfaceDefAndUse.f(::T, ::T) = 1
end

module Factory
using IfaceImpl

export l
l() = IfaceImpl.T()
end

module User
using Factory
using WrapperOfIfaceUse

m() = WrapperOfIfaceUse.k(Factory.l(), Factory.l())
m()
end

Now in the call chain, User.m → WrapperOfIfaceUse.k → IfaceDefAndUse.f no one is aware of IfaceImpl since that is an implementation detail as far as the user, who put them together, is concerned.

1 Like