3 ms·
Adding to the list - the way it treats namespaces. "using Library1, Library2" at the top of a file makes it difficult to figure out where each function comes f
by jstx1 5y ago
Adding to the list - the way it treats namespaces.
"using Library1, Library2" at the top of a file makes it difficult to figure out where each function comes from. It's like "import *" in Python.
- jakobnissen 5y agoYes, I should have added that. It intersect with the type system in a complicated matter, since two functions can co-exist in the same namespace as long as their signatures are incompatible. Which of course means that, if I'm correct that the community is moving away from type signature as much as possible (they will still be needed to some extent to control dispatch), the problem of namespace collisions will increase over time.
- Certhas 5y agoI think you're completely right with this observation. In practice much of Julia is duck typed. It uses types to pass information from the outermost caller to the compiler of the inner functions, not to express invariants. Human annotations get in the way of that, and thus get in the way of composability. You want to annotate Interfaces in Julia, not types. But we don't have interfaces.
- WanderPanda 5y agoAren't namespace collisions the feature that makes multiple dispatch so composable? I think this is what allows to replace the built in Arrays by GPUArrays and most of the code should still work because all the major operators and functions have GPU implementations
- BadInformatics 5y agoThey aren't collisions so much as overloads. e.g. GPUArrays implements the same base AbstractArray methods. I'm not a big fan of using either (in any language) because it obscures where imports come from, and AFAICT overloads are created even with a plain import.
- kristofferc 5y ago> since two functions can co-exist in the same namespace as long as their signatures are incompatible. This doesn't really make any sense. You can only have one function in each namespace, this function can have multiple methods extending that function. As long as you are not doing type piracy you will not implement the same method in e.g. different packages. The problem with `using` is mostly about that it is unclear from what namespace a symbol comes from since it isn't visible lexically.
- ellisv 5y agothis works fine for me import Dates Dates.today()
- gugagore 5y agoIt is a lot safer than `from pkgfoo import *` because you get a warning if there is a collision. $ julia --banner=no julia> module A export foo foo(x) = x end Main.A julia> module B export foo foo(x) = x + 1 end Main.B julia> using .A julia> foo(1) 1 julia> using .B WARNING: using B.foo in module Main conflicts with an existing identifier. julia> foo(1) 1 julia> B.foo(1) 2