Allow top-level shadowing for imported names?

amindfv at amindfv at
Wed Oct 5 16:34:14 UTC 2016

I'm weakly against this proposal. I may compile with -Wall, but I read code by many people who don't. When I'm browsing a file and see e.g.

import Network.Socket

and then later in the file, I see a reference to "recvFrom", I currently know exactly what function is being called. I don't want to have to search around every time to make sure a function wasn't redefined in some dark corner of the module.

This allows too much "sneakiness" for my taste.


> On Oct 3, 2016, at 04:29, Herbert Valerio Riedel <hvriedel at> wrote:
> Hi *,
> I seem to recall this was already suggested in the past, but I can't
> seem to find it in the archives. For simplicity I'll restate the idea:
>    foo :: Int -> Int -> (Int,Int)
>    foo x y = (bar x, bar y)
>      where
>        bar x = x+x
> results merely in a name-shadowing warning (for -Wall):
>    foo.hs:4:9: warning: [-Wname-shadowing]
>        This binding for ‘x’ shadows the existing binding
>          bound at foo.hs:2:5
> However,
>    import Data.Monoid
>    (<>) :: String -> String -> String
>    (<>) = (++)
>    main :: IO ()
>    main = putStrLn ("Hi" <> "There")
> doesn't allow to shadow (<>), but rather complains about ambiguity:
>    bar.hs:7:23: error:
>        Ambiguous occurrence ‘<>’
>        It could refer to either ‘Data.Monoid.<>’,
>                                 imported from ‘Data.Monoid’ at bar.hs:1:1-18
>                              or ‘Main.<>’, defined at bar.hs:4:1
> This is of course in line with the Haskell Report, which says in
> | The entities exported by a module may be brought into scope in another
> | module with an import declaration at the beginning of the module. The
> | import declaration names the module to be imported and optionally
> | specifies the entities to be imported. A single module may be imported
> | by more than one import declaration. Imported names serve as top level
> | declarations: they scope over the entire body of the module but may be
> | shadowed by *local non-top-level bindings.*
> However, why don't we allow this to be relaxed via a new language
> extensions, to allow top-level bindings to shadow imported names (and
> of course emit a warning)?
> Unless I'm missing something, this would help to keep existing and
> working code compiling if new versions of libraries start exporting new
> symbols (which happen to clash with local top-level defs), rather than
> resulting in a fatal name-clash; and have no major downsides.
> If this sounds like a good idea, I'll happily promote this into a proper
> proposal over at; I
> mostly wanted to get early feedback here (and possibly find out if and
> where this was proposed before), before investing more time turning
> this into a fully fledged GHC proposal.
> Cheers,
>  HVR
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at

More information about the ghc-devs mailing list