Allow top-level shadowing for imported names?
Simon Peyton Jones
simonpj at microsoft.com
Mon Oct 3 09:44:08 UTC 2016
Fine with me!
| -----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)
| 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
| 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
| 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
| | module with an import declaration at the beginning of the module.
| | import declaration names the module to be imported and optionally
| | specifies the entities to be imported. A single module may be
| | by more than one import declaration. Imported names serve as top
| | declarations: they scope over the entire body of the module but may
| | 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
| 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.
More information about the ghc-devs