Allow top-level shadowing for imported names?

[Edward Kmett]

I for one would really like to see this go in. (I've commiserated with
Lennart in the past about the fact that the previous proposal just sort of
died.)

It makes additions of names to libraries far less brittle. You can add a
new export with a mere minor version bump, and many of the situations where
that causes breakage can be fixed by this simple rule change.

-Edward

On Mon, Oct 3, 2016 at 2:12 PM, Iavor Diatchki <iavor.diatchki at gmail.com>
wrote:

> Hi,
>
> Lennart suggested that some time ago, here is the thread from the last
> time we discussed it:
>
> https://mail.haskell.org/pipermail/haskell-prime/2012-July/003702.html
>
> I think it is a good plan!
>
> -Iavor
>
>
>
> On Mon, Oct 3, 2016 at 4:46 AM, Richard Eisenberg <rae at cs.brynmawr.edu>
> wrote:
>
>> By all means make the proposal -- I like this idea.
>>
>> > On Oct 3, 2016, at 4:29 AM, 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
>>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20161004/605cc4a8/attachment.html>