On Sun, 22 May 2016, Jeremy . wrote:
1. If the compiler encounters a term f a, and there is more than one definition for f in scope (after following all of the usual rules for qualified imports);
2. And exactly one of these definitions matches the type of a (or the expected type of f if given);
3. Then this is the definition to use.
I know people are unhappy with Haskell's records and module system, but I still think that's because these language features are not used properly. Type classes are the tool to write generic code and reduce combinatoric explosion of functions and modules are a way to collect functions per type. Following this principle you give function names that make sense together with the module name like File.write or Channel.write. Then there is no need for the compiler to disambiguate unqualified identifiers and you keep the type and the module issues separated. Today, if you stick to the unqualified style, and I guess you want to import modules without explicit identifier list, too, then your code can break whenever the imported modules add identifiers. In order to prevent this you have to use tight package import version bounds in your Cabal file. Your proposal would not solve this problem. Type-driven name resolution may disambiguate identifiers in some case but not in all ones, thus you still need to use tight version bounds. The proposal seems to be a big complication. The compiler can no longer emit a message: "Type of function f mismatch", but it has to emit "If f means A.f, then the type error would be ..., but if it means B.f, then the type error would be ..." Or even worse: "If f means A.f and g means C.g, then the type error would be ... if f means B.f and g means C.g ... or f means A.f and g means D.g ..." The proposal also is more error-prone, because if you make a type-error this could be shadowed by a function in scope with a type that matches accidentally. A function with a very generic type and a generic name might be such an accidental match. That said, the more complicated the proposals become the more one should reconsider about whether one runs in the right direction. I think this is the case here. The simple answer could be: Switch to a cleaner coding style!