Hacker News Reader

Comment by jakobnissen | Hacker News Reader

Yes, 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.

View on HN

I 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.

Aren'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

They 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.

> 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.

Reply on news.ycombinator.com