I would find a third meaning for dot in Haskell just a little bit too many. Especially with hierarchical modules, Haskell encourages writing small modules, or at any rate no larger than they have to be. (SML goes further, of course.) So if we're doing what the software engineering books say (small highly cohesive loosely coupled modules) we should have that much of a name overloading problem in the first place, no? The alias facility for imports, and the practice that has sprung up of using single-letter abbreviations for modules, make the existing practice fairly light-weight. I'm not sure, therefore, that we have a problem that OUGHT to be "solved", still less by a method that I find less readable. It seems to me that there's an approach that could be swiped from ML. One of the declaration forms in ML is local <private declarations> in <public declarations> end Just as "where" lets you share a bunch of definitions across a bunch of clauses, so "local" makes everything in the <private declarations> visible inside the <public declarations> but not outside; from the outside only the <public declaration> can be seen. Waving my hands a bit, this is roughly equivalent to (x1,...,xn) = let <private declarations> in let <public declarations> in (x1,...,xn) What has this to do with imports? It means that you can introduce local renamings that can be _shared_ by a group of declarations, while elsewhere in the module, another group of declarations can share different resolutions for the same names. The advantages of that over type directed resolution include - what's happening is visible to the programmer - it's basically ordinary declarations, not some new constraint satisfaction process that has to be interwoven somehow with type inference - that makes life easier for other tools as well - it doesn't overload dot (or my small head)