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.
| 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: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow- | haskell-users-bounces@haskell.org] On Behalf Of John Lato | Sent: 17 August 2012 02:13 | To: glasgow-haskell-users@haskell.org | 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 | Glasgow-haskell-users@haskell.org | 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
Sounds reasonable. We might want flags to go with it for silencing or enabling that particular warning. -- Dan Burton
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
Sounds reasonable. We might want flags to go with it for silencing or enabling that particular warning.
-- Dan Burton
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org 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:carter.schonwald@gmail.com]
Sent: Sunday, August 19, 2012 11:10 AM
To: Dan Burton
On Sat, Aug 18, 2012 at 9:10 PM, Carter Schonwald < carter.schonwald@gmail.com> 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". -- brandon s allbery allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms
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
participants (8)
-
Bertram Felgenhauer -
Brandon Allbery -
Carter Schonwald -
Dan Burton -
Ganesh Sittampalam -
I-Aldridge, Peter -
John Lato -
Simon Peyton-Jones