<div dir="ltr">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.)<div><br></div><div>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.<div><br></div><div>-Edward</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 3, 2016 at 2:12 PM, Iavor Diatchki <span dir="ltr"><<a href="mailto:iavor.diatchki@gmail.com" target="_blank">iavor.diatchki@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>Lennart suggested that some time ago, here is the thread from the last time we discussed it:</div><div><br></div><div><a href="https://mail.haskell.org/pipermail/haskell-prime/2012-July/003702.html" target="_blank">https://mail.haskell.org/<wbr>pipermail/haskell-prime/2012-<wbr>July/003702.html</a><br></div><div><br></div><div>I think it is a good plan!</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>-Iavor</div><div><br></div><div><br></div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 3, 2016 at 4:46 AM, Richard Eisenberg <span dir="ltr"><<a href="mailto:rae@cs.brynmawr.edu" target="_blank">rae@cs.brynmawr.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">By all means make the proposal -- I like this idea.<br>
<div class="m_-2488840924412867315HOEnZb"><div class="m_-2488840924412867315h5"><br>
> On Oct 3, 2016, at 4:29 AM, Herbert Valerio Riedel <<a href="mailto:hvriedel@gmail.com" target="_blank">hvriedel@gmail.com</a>> wrote:<br>
><br>
> Hi *,<br>
><br>
> I seem to recall this was already suggested in the past, but I can't<br>
> seem to find it in the archives. For simplicity I'll restate the idea:<br>
><br>
><br>
>    foo :: Int -> Int -> (Int,Int)<br>
>    foo x y = (bar x, bar y)<br>
>      where<br>
>        bar x = x+x<br>
><br>
> results merely in a name-shadowing warning (for -Wall):<br>
><br>
>    foo.hs:4:9: warning: [-Wname-shadowing]<br>
>        This binding for ‘x’ shadows the existing binding<br>
>          bound at foo.hs:2:5<br>
><br>
><br>
> However,<br>
><br>
>    import Data.Monoid<br>
><br>
>    (<>) :: String -> String -> String<br>
>    (<>) = (++)<br>
><br>
>    main :: IO ()<br>
>    main = putStrLn ("Hi" <> "There")<br>
><br>
> doesn't allow to shadow (<>), but rather complains about ambiguity:<br>
><br>
>    bar.hs:7:23: error:<br>
>        Ambiguous occurrence ‘<>’<br>
>        It could refer to either ‘Data.Monoid.<>’,<br>
>                                 imported from ‘Data.Monoid’ at bar.hs:1:1-18<br>
>                              or ‘Main.<>’, defined at bar.hs:4:1<br>
><br>
><br>
> This is of course in line with the Haskell Report, which says in<br>
> <a href="https://www.haskell.org/onlinereport/haskell2010/haskellch5.html#x11-1010005.3" rel="noreferrer" target="_blank">https://www.haskell.org/online<wbr>report/haskell2010/haskellch5.<wbr>html#x11-1010005.3</a><br>
><br>
> | The entities exported by a module may be brought into scope in another<br>
> | module with an import declaration at the beginning of the module. The<br>
> | import declaration names the module to be imported and optionally<br>
> | specifies the entities to be imported. A single module may be imported<br>
> | by more than one import declaration. Imported names serve as top level<br>
> | declarations: they scope over the entire body of the module but may be<br>
> | shadowed by *local non-top-level bindings.*<br>
><br>
><br>
> However, why don't we allow this to be relaxed via a new language<br>
> extensions, to allow top-level bindings to shadow imported names (and<br>
> of course emit a warning)?<br>
><br>
> Unless I'm missing something, this would help to keep existing and<br>
> working code compiling if new versions of libraries start exporting new<br>
> symbols (which happen to clash with local top-level defs), rather than<br>
> resulting in a fatal name-clash; and have no major downsides.<br>
><br>
> If this sounds like a good idea, I'll happily promote this into a proper<br>
> proposal over at <a href="https://github.com/ghc-proposals/ghc-proposals" rel="noreferrer" target="_blank">https://github.com/ghc-proposa<wbr>ls/ghc-proposals</a>; I<br>
> mostly wanted to get early feedback here (and possibly find out if and<br>
> where this was proposed before), before investing more time turning<br>
> this into a fully fledged GHC proposal.<br>
><br>
> Cheers,<br>
>  HVR<br>
</div></div><div class="m_-2488840924412867315HOEnZb"><div class="m_-2488840924412867315h5">> ______________________________<wbr>_________________<br>
> ghc-devs mailing list<br>
> <a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bi<wbr>n/mailman/listinfo/ghc-devs</a><br>
<br>
______________________________<wbr>_________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bi<wbr>n/mailman/listinfo/ghc-devs</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/ghc-devs</a><br>
<br></blockquote></div><br></div>