Allow top-level shadowing for imported names?

[Yuras Shumovich]

On Tue, 2016-10-04 at 04:48 -0400, Edward Kmett wrote:

> 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.

It would be true only if we also allow imports to shadow each other.
Otherwise there will be a big chance for name clash yet.

Can we generalize the proposal such that subsequent imports shadow
preceding ones? In that case you may e.g. list local modules after
libraries' modules, and be sure new identifies in libraries will not
clash with local ones. Obviously shadowing should be a warning still.

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