Re: Allow top-level shadowing for imported names?

[Yitzchak Gale]

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 fixes an inconsistency and thus simplifies Haskell syntax.

So in my opinion this is not a cleverness proposal, it's a
simplication.

> 2) There is no good way to use this feature without creating a
> warning.

I'm not sure what you mean. There is already a warning for
shadowing. Except shadowing from imports, where it is an
error instead. The proposal is to eliminate that special
case.

>  I would like to be explicit in my name shadowing  I'm
> thinking a pragma like {-# NO_WARN myFunction #-},
> or, better yet, the more specific
> {-# SHADOWING myFunction #-} orso.

The same applies to shadowing in every other context.
Adding such a pragma might indeed be a nice idea. But
it should apply consistently to shadowing in all contexts,
not just for import shadowing. In any case, this
would be a separate proposal.

-Yitz
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Allow top-level shadowing for imported names?

[Brandon Allbery]

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")
>
> -- NOTE: 0 indent!
>
> where
> (<>) :: String -> String -> String
> (<>) = (++)
>

This would actually be slightly odd parse-wise, as we're already *in* an
unindented where clause (module ... where)

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Allow top-level shadowing for imported names?

[Christopher Allen]

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

Re: Allow top-level shadowing for imported names?

[amindfv]

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

Re: Allow top-level shadowing for imported names?

[Carter Schonwald]

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 different idea...
> > allowing explicitly enumerated names...
> > to shadow imports from other modules which didn't explicitly name the
> > same import; effectively introducing a higher-priority scope for names
> > imported explicitly.
>
> Conversely - the original proposal should be modified to remain
> an error, not a warning, when the symbol was imported explicitly
> on an import list and then redefined locally at the top level.
> This is equivalent to defining a symbol twice in the same scope.
>
> Thanks,
> Yitz
> ___
> 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

Re: Allow top-level shadowing for imported names?

[Yitzchak Gale]

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
> same import; effectively introducing a higher-priority scope for names
> imported explicitly.

Conversely - the original proposal should be modified to remain
an error, not a warning, when the symbol was imported explicitly
on an import list and then redefined locally at the top level.
This is equivalent to defining a symbol twice in the same scope.

Thanks,
Yitz
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Allow top-level shadowing for imported names?

[Edward Z. Yang]

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 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 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?
> 
> IMO, that would be lead to fragile situations with hard to detect/debug
> problems unless you take warnings serious.
> 
> With the original proposal, the semantics of your code doesn't change if
> a library starts exposing a name it didn't before. There is a clear
> priority of what shadows what.
> 
> However, when we allow the ordering of import statements to affect
> shadowing, it gets more brittle and surprising imho:
> 
> For one, we have tooling which happily reorders/reformats import
> statements which would need to be made aware that the reordering
> symmetry has been broken.
> 
> Moreover, now we get into the situation that if in
> 
>   import Foo -- exports performCreditCardTransaction
>   import Bar
> 
>   main = do
>  -- ..
>  performCreditCardTransaction ccNumber
>  --
> 
> 'Bar' suddenly starts exporting performCreditCardTransaction as well
> (and doing something sinister with the ccNumber before handing it over
> to the real performCreditCardTransaction...), it can effectively change
> the semantics of a program and this would merely emit a warning which
> imho rather deserves to be a hard error.
> 
> However, iirc there is a different idea to address this without breaking
> reordering-symmetry, e.g. by allowing explicitly enumerated names as in
> 
>   import Foo (performCreditCardTransaction)
>   import Bar
> 
> to shadow imports from other modules which didn't explicitly name the
> same import; effectively introducing a higher-priority scope for names
> imported explicitly.
> 
> > 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.
> 
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Allow top-level shadowing for imported names?

[Reid Barton]

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

Could you give a concrete example of what you are worried about? It's
already legal to have a clash between imported names as long as you
don't refer to the colliding name. For example if one of my imports A
exports a name `foo` which I don't use, and then another import B
starts to export the same name `foo`, there won't be any error as long
as I continue to not use `foo`.

Regards,
Reid Barton
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Allow top-level shadowing for imported names?

[Elliot Cameron]

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 
wrote:

> 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 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?
>
> IMO, that would be lead to fragile situations with hard to detect/debug
> problems unless you take warnings serious.
>
> With the original proposal, the semantics of your code doesn't change if
> a library starts exposing a name it didn't before. There is a clear
> priority of what shadows what.
>
> However, when we allow the ordering of import statements to affect
> shadowing, it gets more brittle and surprising imho:
>
> For one, we have tooling which happily reorders/reformats import
> statements which would need to be made aware that the reordering
> symmetry has been broken.
>
> Moreover, now we get into the situation that if in
>
>   import Foo -- exports performCreditCardTransaction
>   import Bar
>
>   main = do
>  -- ..
>  performCreditCardTransaction ccNumber
>  --
>
> 'Bar' suddenly starts exporting performCreditCardTransaction as well
> (and doing something sinister with the ccNumber before handing it over
> to the real performCreditCardTransaction...), it can effectively change
> the semantics of a program and this would merely emit a warning which
> imho rather deserves to be a hard error.
>
> However, iirc there is a different idea to address this without breaking
> reordering-symmetry, e.g. by allowing explicitly enumerated names as in
>
>   import Foo (performCreditCardTransaction)
>   import Bar
>
> to shadow imports from other modules which didn't explicitly name the
> same import; effectively introducing a higher-priority scope for names
> imported explicitly.
>
> > 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.
>
> ___
> 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

Re: Allow top-level shadowing for imported names?

[Herbert Valerio Riedel]

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

IMO, that would be lead to fragile situations with hard to detect/debug
problems unless you take warnings serious.

With the original proposal, the semantics of your code doesn't change if
a library starts exposing a name it didn't before. There is a clear
priority of what shadows what.

However, when we allow the ordering of import statements to affect
shadowing, it gets more brittle and surprising imho:

For one, we have tooling which happily reorders/reformats import
statements which would need to be made aware that the reordering
symmetry has been broken.

Moreover, now we get into the situation that if in

  import Foo -- exports performCreditCardTransaction
  import Bar

  main = do
 -- ..
 performCreditCardTransaction ccNumber
 --

'Bar' suddenly starts exporting performCreditCardTransaction as well
(and doing something sinister with the ccNumber before handing it over
to the real performCreditCardTransaction...), it can effectively change
the semantics of a program and this would merely emit a warning which
imho rather deserves to be a hard error.

However, iirc there is a different idea to address this without breaking
reordering-symmetry, e.g. by allowing explicitly enumerated names as in

  import Foo (performCreditCardTransaction)
  import Bar

to shadow imports from other modules which didn't explicitly name the
same import; effectively introducing a higher-priority scope for names
imported explicitly.

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

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: 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  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  > edu>
> > wrote:
> > 
> > > 
> > > By all means make the proposal -- I like this idea.
> > > 
> > > > 
> > > > On Oct 3, 2016, at 4:29 AM, Herbert Valerio Riedel  > > > 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@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
> > > 
> > 
> > 
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> > 
> > 
> ___
> 

Re: Allow top-level shadowing for imported names?

[Edward Kmett]

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 where
that causes breakage can be fixed by this simple rule change.

-Edward

On Mon, Oct 3, 2016 at 2:12 PM, Iavor Diatchki 
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.html
>
> I think it is a good plan!
>
> -Iavor
>
>
>
> On Mon, Oct 3, 2016 at 4:46 AM, Richard Eisenberg 
> wrote:
>
>> 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:
>> >
>> >
>> >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
>>
>
>
> ___
> 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

Re: Allow top-level shadowing for imported names?

[Richard Eisenberg]

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

RE: Allow top-level shadowing for imported names?

[Simon Peyton Jones via ghc-devs]

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 *,
|  
|  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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu
|  b.com%2Fghc-proposals%2Fghc-
|  proposals=01%7C01%7Csimonpj%40microsoft.com%7C6cb5253b609241e0b10
|  008d3eb675d5e%7C72f988bf86f141af91ab2d7cd011db47%7C1=COdAXpXOOox
|  mAnZSBnJfbF%2BTctssVUlqn%2BiccABrkF0%3D=0; 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

Re: Allow top-level shadowing for imported names?

[Edward Z. Yang]

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

Allow top-level shadowing for imported names?

[Herbert Valerio Riedel]

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


pgpmTqGogQqM8.pgp
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs