I think Jeff has hit the nail on the head here: the original proposal in this thread (which has been derailed with more ADL discussion) is fundamentally about dynamic scoping. In essence, it seems that in the proposal, which function is called is dynamically scoped (other variables remain lexically scoped, however, which is a bit inconsistent, but it’s just a proposal, so let’s go with it). Historically, dynamic scope was used in early Lisps, but it has largely fallen out of favor. The reason is precisely the objection that’s been given to this proposal: it makes it impossible to reason locally about the meaning of code since the meaning depends on the caller, which is not statically knowable.
I want to address the three issues that this proposal purports to solve:
Type piracy. Yes, it’s usually bad if you redefine what +
on integers means. But I have not seen this to be a very large problem. People do it once at the REPL, Julia crashes almost immediately, and then they don’t do it again. We’ve contemplated having a way to seal certain functions or subsets of a function’s signature to prevent this, but it’s just not a high priority since it’s not a real problem in the wild. And sometimes type piracy is just fine and even useful. The notion that it’s an absolute evil is not something that the Julia core team has promulgated. We also didn’t coin the phrase “type piracy” although I do find it delightful.
Conflicting names. I think most of the ADL discussion applies here, so I’m not going to rehash it. Everything I said at the end of this post applies. Conflicting names can be an annoyance, but it’s not the end of the world. In case of conflict, be explicit: import or qualify. There’s no free lunch.
Binary compilation. Yes, Julia currently has a compile time problem. And yes, we very much need to be able to cache machine code in .ji
files. But neither of these things have anything to do with how method extension works. The former is mostly a problem with LLVM getting a bit obese over the years and us adding more and more sophisticated optimizations—which everyone loves but which don’t come for free. The latter is just a matter of doing the work, which not very many people are able to do—and the ones that can have been busy getting 1.0 ready.
There are many features of Julia which cause us to generate a lot of code—aggressive specialization on argument types, specialization on function values, lots of inlining, implicit templatization of parametric types—but the way multiple dispatch and method extension work is not one of them.