Fine with me! Simon
| -----Original Message----- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of | Herbert Valerio Riedel | Sent: 03 October 2016 09:29 | To: ghc-devs <ghc-devs@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 _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs