Cale et al, I have a concern about the implementation of the proposed TypeDirectedNameResolution. (I'm not familiar with the internals of any of the compilers, so it could be that my concern isn't well founded.) I'm assuming that name resolution is currently independent of type inference, and will happen before type inference. With the proposal this is no longer true, and in general some partial type inference will have to happen before conflicting unqualified names are resolved. My worry is that the proposal will require a compliant compiler to interweave name resolution and type inference iteratively. Give the Haskell source code: import X import Y import Z a = 1 + (1 :: Integer) b = x a c = y b d = z c . . . Assume X, Y, and Z all export x, y, and z. The compiler might do something like this: (do stuff) Infer type of 'a' Resolve unqualified use of 'x' in "x a" Infer type of 'b' from "b = x a" Resolve unqualified use of 'y' in "y b" Infer type of 'c' from "c = y b" Resolve unqualified use of 'z' in "z c" etc. If ambiguous unqualified names are used mutually recursively it may be that there's only one reasonable combination of name resolutions, but is this decidable? To my untrained eye it looks complicated and invasive, even without the mutually recursive case. Can anyone shed light on whether this would be a problem for, say, GHC? Thanks, John