Allow top-level shadowing for imported names?

[Christopher Allen]

I agree with Tom on this. This isn't a good way to spend the cleverness budget.

On Wed, Oct 5, 2016 at 11:34 AM,  <amindfv at gmail.com> wrote:
> I'm weakly against this proposal. I may compile with -Wall, but I read code by many people who don't. When I'm browsing a file and see e.g.
>
> import Network.Socket
>
> and then later in the file, I see a reference to "recvFrom", I currently know exactly what function is being called. I don't want to have to search around every time to make sure a function wasn't redefined in some dark corner of the module.
>
> This allows too much "sneakiness" for my taste.
>
> Tom
>
>
>> On Oct 3, 2016, at 04:29, Herbert Valerio Riedel <hvriedel at gmail.com> 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.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
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



-- 
Chris Allen
Currently working on http://haskellbook.com