Allow top-level shadowing for imported names?

[Iavor Diatchki]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20161003/12c27877/attachment.html>