It's occurred to me that a much simpler description of the proposed change would be automatically lifting *uses* of the explicitly imported variable to a qualified use, /if/ there was only one explicit import of the identifier. For instance, with the following import: import Data.Text.Lazy.IO (putStrLn) import Prelude import qualified Data.List as L import qualified MyModule as L (isInfixOf) automatically change any unqualified (and un-shadowed) use of putStrLn to Data.Text.Lazy.IO.putStrLn, and any use of L.infixOf to MyModule.isInfixOf. The latter should be easier to implement covering a number of corner cases: * you can still refer to Prelude.putStrLn or Data.List.isInfixOf by prepending the path, which the naive auto-hiding transformation would prevent. * possibly easier to have the pragma available to use in GHCi, since you don't need to retroactively hide identifiers from previously imported modules when a new explicit import is made. * works better with imports like "import Data.Either (Either(..)); import MyModule (Left)", which would otherwise require translating the Data.Either import to something like "import Data.Either (Either(..)) hiding (Left)" which isn't currently possible or "import Data.Either (Either(Right))" which can't be done without knowing which modules export which identifiers. The only remaining corner case is if you shadow the name of a module like: import Data.Text.Lazy.IO (putStrLn) import Prelude as Data.Text.Lazy.IO An unqualified user of putStrLn /should/ refer to the text version, but if anything translating it to Data.Text.Lazy.IO.putStrLn makes it more ambiguous. I assume GHC can disambiguate even if the user can't, or if you didn't want to cover that case the existing ambiguous identifier occurrence error could still fire. Really just depends where in the pipeline the change is implemented. I suppose I'll describe both possible implementations. Functionally they're the same, but maybe this one is simpler. -- View this message in context: http://haskell.1045720.n5.nabble.com/Hiding-import-behaviour-tp5758155p57584... Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.