
OK. I've created a ticket https://ghc.haskell.org/trac/ghc/ticket/10117 In fact there is a pretty good specification here https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/UnusedImports So back to you: based on the existing, can you think of a variant that would work better? Simon | -----Original Message----- | From: Herbert Valerio Riedel [mailto:hvriedel@gmail.com] | Sent: 24 February 2015 12:00 | To: Simon Peyton Jones | Cc: Herbert Valerio Riedel; Johan Tibell; Edward Kmett; Austin Seipp | Subject: Re: The suggested redundant import solution doesn't work for | explicit import lists | | Simon, | | The problem: | | trying to avoid redundant-import warnings due symbols having moved to | 'Prelude' due to AMP/FTP w/o CPP usage | | e.g. | | import Control.Applicative (Applicative) | | foo :: Applicative f => ... | foo = ... | | now warns that 'Applicative' is redundant, as it's exported from | 'Prelude' now. 'Monoid' is another such example that's now re-exported | from 'Prelude' (but wasn't before GHC 7.10). | | | One thing that happens to work is the trick shown at | https://ghc.haskell.org/trac/ghc/wiki/Migration/7.10#GHCsaysTheimporto | f...isredundant | i.e. | | module Foo (Int, Word, Monoid(..)) where | | import Data.Monoid | import Data.Word | import Prelude | | as in that case, 'Prelude' is explicitly imported last, and so GHC | doesn't warn about Data.{Word,Monoid} being redundant (due to the way | the redundancy-check is implemented in GHC) | | However, if the example above is rewritten as | | module Foo (Int, Word, Monoid(..)) where | | import Data.Monoid (Monoid(..)) | import Data.Word (Word) | import Prelude | | GHC would warn, as it handles import-listed symbols differently than | wildcard imports... | | and the question is, whether we can easily get the latter example to | become warning free as well w/o risking breakages elsewhere... | | ...is it clearer now what I'm suggesting? | | Cheers, | hvr | | On 2015-02-24 at 12:50:35 +0100, Simon Peyton Jones wrote: | > I'm sorry, but can someone re-articulate the question? I'm deep | underwater, so reluctant to reverse-engineer the question from the | thread. | > I think you are asking for some feature. But I'm not sure what the | spec is. | > | > Simon | > | > | -----Original Message----- | > | From: Herbert Valerio Riedel [mailto:hvriedel@gmail.com] | > | Sent: 24 February 2015 11:29 | > | To: Johan Tibell | > | Cc: Edward Kmett; Simon Peyton Jones; Austin Seipp | > | Subject: Re: The suggested redundant import solution doesn't work | > | for explicit import lists | > | | > | Johan, | > | | > | You're right, I'm afraid the Prelude-trick doesn't work well with | > | import-lists... not sure though if it's worth the risk to tweak | GHC | > | 7.10.1's redundant-warning detection to make it work here too... | > | | > | @SPJ, any comments? | > | | > | for more context: | > | | > | - | > | | https://ghc.haskell.org/trac/ghc/wiki/Migration/7.10#GHCsaysTheimporto | f.. | > | .isredundant | > | - | > | | http://www.reddit.com/r/haskell/comments/2wx64g/ghc_710_will_use_pla | > | n_ftp | > | /covdas0 | > | | > | Cheers, | > | hvr | > | | > | On 2015-02-24 at 11:47:30 +0100, Johan Tibell wrote: | > | > The suggested fix for unused imports resulting from the move of | e.g. | > | > Data.Monoid doesn't work when using explicit import lists: | > | > | > | > $ cat Test.hs | > | > module Test where | > | > | > | > import Data.Monoid (Monoid) | > | > import Prelude | > | > | > | > f :: Monoid a => a | > | > f = undefined | > | > $ ghc-7.10.0.20150123 -Wall /tmp/Test.hs | > | > [1 of 1] Compiling Test ( /tmp/Test.hs, /tmp/Test.o | ) | > | > | > | > /tmp/Test.hs:3:1: Warning: | > | > The import of ‘Data.Monoid’ is redundant | > | > except perhaps to import instances from ‘Data.Monoid’ | > | > To import instances alone, use: import Data.Monoid() | > | > | > | > It does work if you don't have an import list (bad idea) or use | > | qualified | > | > imports (good idea). | > | > | > | > -- Johan | > | | > | -- | > | "Elegance is not optional" -- Richard O'Keefe | | -- | "Elegance is not optional" -- Richard O'Keefe