Hi, I cannot speak about limitations during the compile process, but at a high level, I don't see why (with a few small tweaks) Julia's multiple dispatch system cannot deal with most of the issues discussed here.
>From what I see, there appears to be 3 issues that cause most of the headaches: 1) A module seems to "own" a function. 2) "using" seems to pull names/symbols into the global namespace/scope (Main?) instead of the local one (whichever module the code resides). 3) Module developers "export" functions that cannot be resolved by multiple dispatch. I believe items 2 & 3 are well covered in "Using ModX: Can scope avoid collisions & improve readability?": https://groups.google.com/d/msg/julia-users/O8IpPdYBkLw/XzpFj9qiGzUJ As for item 1, the next section should provide clarification: *****A module seems to "own" a function***** Well, my biggest problem is that if you want to reuse the word "open" for your particular application, you need to re-implement base.open(...). This requirement seems a bit awkward. Should you not just be able to implement your own "MyModule.open" as long as it can uniquely be resolved through multiple dispatch? In that case applying "using Base & using MyModule" should be able to merge the two "open" functions without ambiguity... as long as Base.open was defined with an interface that is unique: #Sample Base module: module Base abstract Stream abstract FileType <: Stream type BinaryFile <: FileType ...; end function open(::Type{BinaryFile}, ...) ... end export Stream, FileType, BinaryFile export open end #Base #Implement my own socket communication: module MySocketMod type MySocket <: Base.Stream ...; end function open(::Type{MySocket}, ...) ... end export MySocket export open end #MySocketMod #Try out the code: using Base using MySocketMod #No problem... "open" ambiguities are covered by mulit-dispatch. #Great! No abiguities: myfile = open(BinaryFile, ...) mysocket = open(MySocket, ...) Sure, the extra argument in "open" *seems* a bit verbose compared to other languages, but it is a bit easier to read... and the argument *not* really redundant. Indeed, I can see that this solution would require extra compiler complexity - depending on which items are being addressed: A) Merging function specializations from different modules might have to be done at run time - not ideal. B) "using"/importing module functions in a local scope makes the symbol tables much larger - not great either. Having said that, I don't see actual ambiguities here, only additional complexity in the implementation.
