|
Hello,
One of the issues I've noticed with ghc-7.6 is that a number of packages fail due to problematic import statements. For example, any module which uses > import Prelude hiding (catch) now fails to build with the error Module `Prelude' does not export `catch' Of course fixing this example is relatively straightforward, but that isn't always the case. Would it be reasonable to change ghc's behavior to treat this as a warning instead of an error? Cheers, John L. _______________________________________________ Glasgow-haskell-users mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
|
| Would it be reasonable to change ghc's behavior to treat this
| (ie an 'import' statement that hides something that isn't exported) as a | warning instead of an error? Yes, that would be easy if it's what everyone wants. Any other opinions? Simon | -----Original Message----- | From: [hidden email] [mailto:glasgow- | [hidden email]] On Behalf Of John Lato | Sent: 17 August 2012 02:13 | To: [hidden email] | Subject: build failures when hiding non-visible imports | | Hello, | | One of the issues I've noticed with ghc-7.6 is that a number of | packages fail due to problematic import statements. For example, any | module which uses | | > import Prelude hiding (catch) | | now fails to build with the error | | Module `Prelude' does not export `catch' | | Of course fixing this example is relatively straightforward, but that | isn't always the case. | | Would it be reasonable to change ghc's behavior to treat this as a | warning instead of an error? | | Cheers, | John L. | | _______________________________________________ | Glasgow-haskell-users mailing list | [hidden email] | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users _______________________________________________ Glasgow-haskell-users mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
|
Simon Peyton-Jones wrote:
> | Would it be reasonable to change ghc's behavior to treat this > | (ie an 'import' statement that hides something that isn't exported) as a > | warning instead of an error? > > Yes, that would be easy if it's what everyone wants. Any other opinions? +1 for a warning from me Bertram _______________________________________________ Glasgow-haskell-users mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
|
Sounds reasonable. We might want flags to go with it for silencing or enabling that particular warning.
-- Dan Burton _______________________________________________ Glasgow-haskell-users mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
|
meaning: flags for treating it as a warning vs as an error? (pardon, i'm over thinking ambiguity in phrasing).
if thats the desired difference, that sounds good to me! -Carter
On Sat, Aug 18, 2012 at 5:29 PM, Dan Burton <[hidden email]> wrote: Sounds reasonable. We might want flags to go with it for silencing or enabling that particular warning. _______________________________________________ Glasgow-haskell-users mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
|
Peter Aldridge Engineering Operations Manager Boeing Aerostructures Australia Phone: +61 425 818 455
From: Carter Schonwald [mailto:[hidden email]]
meaning: flags for treating it as a warning vs as an error? (pardon, i'm over thinking ambiguity in phrasing).
Sent: Sunday, August 19, 2012 11:10 AM To: Dan Burton <[hidden email]> Cc: [hidden email] <[hidden email]> Subject: Re: build failures when hiding non-visible imports if thats the desired difference, that sounds good to me!
-Carter
On Sat, Aug 18, 2012 at 5:29 PM, Dan Burton
<[hidden email]> wrote:
Sounds reasonable. We might want flags to go with it for silencing or enabling that particular warning. _______________________________________________ Glasgow-haskell-users mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
|
In reply to this post by Carter Schonwald
On Sat, Aug 18, 2012 at 9:10 PM, Carter Schonwald <[hidden email]> wrote:
meaning: flags for treating it as a warning vs as an error? (pardon, i'm over thinking ambiguity in phrasing). I would expect it means that, having demoted it to a warning, we would have -fwarn-hiding-no-target / -fno-warn-hiding-no-target (or whatever we call it) as with all other warnings.
For warning vs. error, it seems to me that should be more general: perhaps taking any of the -f[no-]warn-* options and replacing "warn" with "err". brandon s allbery [hidden email] wandering unix systems administrator (available) (412) 475-9364 vm/sms _______________________________________________ Glasgow-haskell-users mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
|
In reply to this post by Simon Peyton-Jones
On 17/08/2012 11:18, Simon Peyton-Jones wrote:
> | Would it be reasonable to change ghc's behavior to treat this > | (ie an 'import' statement that hides something that isn't exported) as a > | warning instead of an error? > > Yes, that would be easy if it's what everyone wants. Any other opinions? I don't feel strongly either way, but I'd just argue that if it happens it should happen for 7.6.1 to get maximum benefit. Otherwise packages will still need preprocessor hacks to hide Prelude.catch in the meantime (or to use explicit imports from the Prelude, which would be pretty annoying). Cheers, Ganesh _______________________________________________ Glasgow-haskell-users mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
|
In reply to this post by John Lato-2
> From: Brandon Allbery <[hidden email]>
> > On Sat, Aug 18, 2012 at 9:10 PM, Carter Schonwald < > [hidden email]> wrote: > >> meaning: flags for treating it as a warning vs as an error? (pardon, i'm >> over thinking ambiguity in phrasing). >> if thats the desired difference, that sounds good to me! >> > > I would expect it means that, having demoted it to a warning, we would have > -fwarn-hiding-no-target / -fno-warn-hiding-no-target (or whatever we call > it) as with all other warnings. > > For warning vs. error, it seems to me that should be more general: perhaps > taking any of the -f[no-]warn-* options and replacing "warn" with "err". Yes. To be concrete, this is what I would like to see. In a statement of the form: import Module hiding (x) where Module doesn't export x, ghc should report a warning instead of an error This warning would be enabled/disabled by the usual flags (I like -fwarn-unused-import-hiding, but -fwarn-hiding-no-target is good too). The warning would be on by default. If a user wants this to be an error, I think -Werror should be sufficient. I am unable to think of any case where hiding a non-visible symbol would lead to errors on its own, and any errors likely to occur in tandem with this issue already have their own, more helpful, error conditions (e.g. symbols not in scope, symbols in a qualified import list not visible). I agree with Ganesh's point that it would be beneficial to have this available for ghc-7.6.1 if possible. John L. _______________________________________________ Glasgow-haskell-users mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
|
On 21 August 2012 07:36, John Lato <[hidden email]> wrote:
>> From: Brandon Allbery <[hidden email]> >> >> On Sat, Aug 18, 2012 at 9:10 PM, Carter Schonwald < >> [hidden email]> wrote: >> >>> meaning: flags for treating it as a warning vs as an error? (pardon, i'm >>> over thinking ambiguity in phrasing). >>> if thats the desired difference, that sounds good to me! >>> >> >> I would expect it means that, having demoted it to a warning, we would have >> -fwarn-hiding-no-target / -fno-warn-hiding-no-target (or whatever we call >> it) as with all other warnings. >> >> For warning vs. error, it seems to me that should be more general: perhaps >> taking any of the -f[no-]warn-* options and replacing "warn" with "err". > > Yes. To be concrete, this is what I would like to see. > > In a statement of the form: > > import Module hiding (x) > where Module doesn't export x, ghc should report a warning instead of an error > > This warning would be enabled/disabled by the usual flags (I like > -fwarn-unused-import-hiding, but -fwarn-hiding-no-target is good too). > > The warning would be on by default. > > If a user wants this to be an error, I think -Werror should be > sufficient. I am unable to think of any case where hiding a > non-visible symbol would lead to errors on its own, and any errors > likely to occur in tandem with this issue already have their own, more > helpful, error conditions (e.g. symbols not in scope, symbols in a > qualified import list not visible). > > I agree with Ganesh's point that it would be beneficial to have this > available for ghc-7.6.1 if possible. +1 and it must be a warning (not error) by default, or else we will need to tell everyone to use "cabal install --ghc-option=-fwarn-unused-import-hiding" to install lots of packages on hackage (currently including things like HTTP and gtk2hs-buildtools, which are pulled in by many packages). Also, if this remains an error by default then it will become a sensible coding style to simply avoid using import hiding, to avoid build errors that will occur when some other library removes an interface (that you have explicitly marked as unused ...) Conrad. _______________________________________________ Glasgow-haskell-users mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
|
OK we're doing this for 7.6. See http://hackage.haskell.org/trac/ghc/ticket/7167
| -----Original Message----- | From: [hidden email] [mailto:glasgow- | [hidden email]] On Behalf Of Conrad Parker | Sent: 21 August 2012 01:02 | To: John Lato | Cc: [hidden email] | Subject: Re: build failures when hiding non-visible imports | | On 21 August 2012 07:36, John Lato <[hidden email]> wrote: | >> From: Brandon Allbery <[hidden email]> | >> | >> On Sat, Aug 18, 2012 at 9:10 PM, Carter Schonwald < | >> [hidden email]> wrote: | >> | >>> meaning: flags for treating it as a warning vs as an error? | >>> (pardon, i'm over thinking ambiguity in phrasing). | >>> if thats the desired difference, that sounds good to me! | >>> | >> | >> I would expect it means that, having demoted it to a warning, we | >> would have -fwarn-hiding-no-target / -fno-warn-hiding-no-target (or | >> whatever we call | >> it) as with all other warnings. | >> | >> For warning vs. error, it seems to me that should be more general: | >> perhaps taking any of the -f[no-]warn-* options and replacing "warn" | with "err". | > | > Yes. To be concrete, this is what I would like to see. | > | > In a statement of the form: | > | > import Module hiding (x) | > where Module doesn't export x, ghc should report a warning instead of | > an error | > | > This warning would be enabled/disabled by the usual flags (I like | > -fwarn-unused-import-hiding, but -fwarn-hiding-no-target is good | too). | > | > The warning would be on by default. | > | > If a user wants this to be an error, I think -Werror should be | > sufficient. I am unable to think of any case where hiding a | > non-visible symbol would lead to errors on its own, and any errors | > likely to occur in tandem with this issue already have their own, | more | > helpful, error conditions (e.g. symbols not in scope, symbols in a | > qualified import list not visible). | > | > I agree with Ganesh's point that it would be beneficial to have this | > available for ghc-7.6.1 if possible. | | +1 | | and it must be a warning (not error) by default, or else we will need | to tell everyone to use "cabal install --ghc-option=-fwarn-unused- | import-hiding" to install lots of packages on hackage (currently | including things like HTTP and gtk2hs-buildtools, which are pulled in | by many packages). | | Also, if this remains an error by default then it will become a | sensible coding style to simply avoid using import hiding, to avoid | build errors that will occur when some other library removes an | interface (that you have explicitly marked as unused ...) | | Conrad. | | _______________________________________________ | Glasgow-haskell-users mailing list | [hidden email] | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users _______________________________________________ Glasgow-haskell-users mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
| Powered by Nabble | Edit this page |
