Re:The Ergonomics of Type Checking (2016)
by gizmo686 on Saturday October 28, 2017 @11:43PM
(#15577868)
Because a compiler will only load symbols from the current namespace. If you import both Queue.Size and DynamicArray.Size, then try to call Size, the compiler may fail due to the ambiguous reference to "Size". If you wanted access to both of them in the same namespace, you would have to do some form of a qualified import/reference to disambiguate for the compiler. This is the way that any language that does not support overloading handles this, regardless of type system.
It is also possible for the compiler to use type information to attempt to disambiguate. Especially because this would normally happen across module boundaries, a hypothetical compiler could:
1) Infer types based on all non-ambiguous references (or all references within the compilation unit that contains the definition)
2) Disambiguate all ambiguous reference using type information.
I suppose a sufficiently smart compiler could attempt to do type inference and disambiguation at the same time; but that sounds like introducing NP hard problems to the compiler for the sole purpose of allowing confusing code.
It is also possible for the compiler to use type information to attempt to disambiguate. Especially because this would normally happen across module boundaries, a hypothetical compiler could:
1) Infer types based on all non-ambiguous references (or all references within the compilation unit that contains the definition)
2) Disambiguate all ambiguous reference using type information.
I suppose a sufficiently smart compiler could attempt to do type inference and disambiguation at the same time; but that sounds like introducing NP hard problems to the compiler for the sole purpose of allowing confusing code.