Allow top-level shadowing for imported names?

[Simon Peyton Jones]

Fine with me!

Simon

|  -----Original Message-----
|  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
|  Herbert Valerio Riedel
|  Sent: 03 October 2016 09:29
|  To: ghc-devs <ghc-devs at haskell.org>
|  Subject: Allow top-level shadowing for imported names?
|  
|  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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu
|  b.com%2Fghc-proposals%2Fghc-
|  proposals&data=01%7C01%7Csimonpj%40microsoft.com%7C6cb5253b609241e0b10
|  008d3eb675d5e%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=COdAXpXOOox
|  mAnZSBnJfbF%2BTctssVUlqn%2BiccABrkF0%3D&reserved=0; 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