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, <amin...@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 <hvrie...@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@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- Chris Allen Currently working on http://haskellbook.com _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs