Re: Allow top-level shadowing for imported names?

By all means make the proposal -- I like this idea.

On Oct 3, 2016, at 4:29 AM, Herbert Valerio Riedel 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 https://www.haskell.org/onlinereport/haskell2010/haskellch5.html#x11-1010005...

| 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 _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs