Re: Allow top-level shadowing for imported names?

Michael Sloan wrote: > It is really good to think in terms of a cleverness budget... > Here are the things I see in favor of this proposal: > > 1) It is common practice to use -Wall... > 2) It lets us do things that are otherwise quite inconvenient... You missed the most important plus: 0) It

Re: Allow top-level shadowing for imported names?

On Wed, Oct 5, 2016 at 10:02 PM, Michael Sloan wrote: > What if instead we re-framed this as a "top-level where clause", like this: > > main :: IO () > main = putStrLn ("Hi" <> "There") > > other-function :: IO () > other-function = putStrLn ("I can " <> "also use it") > > --

Re: Allow top-level shadowing for imported names?

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

Re: Allow top-level shadowing for imported names?

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

Re: Allow top-level shadowing for imported names?

Yeah... let's not have import order sensitivity. On Wednesday, October 5, 2016, Yitzchak Gale wrote: > Yuras Shumovich wrote: > >> Can we generalize the proposal such that subsequent imports shadow > >> preceding ones? > > Herbert Valerio Riedel wrote: > > ...iirc there is a

Re: Allow top-level shadowing for imported names?

Yuras Shumovich wrote: >> Can we generalize the proposal such that subsequent imports shadow >> preceding ones? Herbert Valerio Riedel wrote: > ...iirc there is a different idea... > allowing explicitly enumerated names... > to shadow imports from other modules which didn't explicitly name the >

Re: Allow top-level shadowing for imported names?

There is another options: names from local modules (same package) shadow names from external packages. But it is not obvious to me that this is a good idea. Edward Excerpts from Herbert Valerio Riedel's message of 2016-10-04 13:50:58 +0200: > Hi, > > On 2016-10-04 at 13:12:54 +0200, Yuras

Re: Allow top-level shadowing for imported names?

On Tue, Oct 4, 2016 at 7:12 AM, Yuras Shumovich wrote: > 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

Re: Allow top-level shadowing for imported names?

I second Herbert's concern. Giving semantics to import order is one of the greatest plagues of C, C++, Python, etc. It is worth avoiding at all costs. Herbert's suggestion re: explicitly enumerated names seems to hold promise, however. On Tue, Oct 4, 2016 at 7:50 AM, Herbert Valerio Riedel

Re: Allow top-level shadowing for imported names?

Hi, On 2016-10-04 at 13:12:54 +0200, Yuras Shumovich wrote: > 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

Re: Allow top-level shadowing for imported names?

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

Re: Allow top-level shadowing for imported names?

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

Re: Allow top-level shadowing for imported names?

By all means make the proposal -- I like this idea. > On Oct 3, 2016, at 4:29 AM, Herbert Valerio Riedel 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: > >

RE: Allow top-level shadowing for imported names?

Fine with me! Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of | Herbert Valerio Riedel | Sent: 03 October 2016 09:29 | To: ghc-devs <ghc-devs@haskell.org> | Subject: Allow top-level shadowing for imported names? | | Hi *, |

Re: Allow top-level shadowing for imported names?

I don't see why not. (But then again I wasn't around for Haskell98!) Edward Excerpts from Herbert Valerio Riedel's message of 2016-10-03 10:29:06 +0200: > 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

Allow top-level shadowing for imported names?

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