Allow top-level shadowing for imported names?

[Herbert Valerio Riedel]

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
https://www.haskell.org/onlinereport/haskell2010/haskellch5.html#x11-1010005.3

| 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 https://github.com/ghc-proposals/ghc-proposals; 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20161003/662bd829/attachment-0001.sig>