How to disable warning for "export item 'module ...' exports nothing"?
Hi, I have a module A that re-exports module B, and module B contains only class instances. Since I'm using -Wall, I get this warning about module B exporting nothing. Is there a way to disable this particular warning, since it is unnecessary in this case? No mailing list messages or GHC documentation has told me what to do. Thanks, Sean
Sean Leather wrote:
Hi,
I have a module A that re-exports module B, and module B contains only class instances. Since I'm using -Wall, I get this warning about module B exporting nothing. Is there a way to disable this particular warning, since it is unnecessary in this case? No mailing list messages or GHC documentation has told me what to do.
Well, the warning is right that you don't need to re-export module B: instances are implicitly exported. So you could just remove the export of "module B", unless there's a reason to export it (such as, you might add some exported functions or data types to it later) -Isaac
I have a module A that re-exports module B, and module B contains only
class instances. Since I'm using -Wall, I get this warning about module B exporting nothing. Is there a way to disable this particular warning, since it is unnecessary in this case? No mailing list messages or GHC documentation has told me what to do.
Well, the warning is right that you don't need to re-export module B: instances are implicitly exported. So you could just remove the export of "module B", unless there's a reason to export it (such as, you might add some exported functions or data types to it later)
Ah, got it. Thanks. I didn't realize instances of an imported module were also implicitly exported. I should have looked at the report, however. For the future reference of others: "Instance declarations cannot be explicitly named on import or export lists. All instances in scope within a module are *always *exported and any import brings *all* instances in from the imported module. Thus, an instance declaration is in scope if and only if a chain of import declarations leads to the module containing the instance declaration." -- 5.4 Importing and Exporting Instance Declarations at http://www.haskell.org/onlinereport/modules.html It would definitely be nice to have a bit more control over importing/exporting instances. I noticed this idea has been discussed a few times already. Sean
I have a module A that re-exports module B, and module B contains only
class instances. Since I'm using -Wall, I get this warning about module B exporting nothing. Is there a way to disable this particular warning, since it is unnecessary in this case? No mailing list messages or GHC documentation has told me what to do.
Well, the warning is right that you don't need to re-export module B: instances are implicitly exported. So you could just remove the export of "module B", unless there's a reason to export it (such as, you might add some exported functions or data types to it later)
Hmm, the disappointing result of removing module B from the export list is that now it doesn't show up in the Haddock-generated documentation for module A. Not that there was anything specific in B to document, because it's only instances. But I do want the user to know that importing A also imports B. Sigh... I suppose there's CPP if I really want it. Sean
Sean Leather wrote:
I have a module A that re-exports module B, and module B contains only
class instances. Since I'm using -Wall, I get this warning about module B exporting nothing. Is there a way to disable this particular warning, since it is unnecessary in this case? No mailing list messages or GHC documentation has told me what to do.
Well, the warning is right that you don't need to re-export module B: instances are implicitly exported. So you could just remove the export of "module B", unless there's a reason to export it (such as, you might add some exported functions or data types to it later)
Hmm, the disappointing result of removing module B from the export list is that now it doesn't show up in the Haddock-generated documentation for module A. Not that there was anything specific in B to document, because it's only instances. But I do want the user to know that importing A also imports B. Sigh... I suppose there's CPP if I really want it.
You could put a link to the module in the intro-documentation that comes before the export list, possibly in a sentence saying e.g. "deliberately exports instances from @module B@" (except I've forgotten Haddock syntax and might have used it wrong there :-) It's an interesting use-case though. I wonder if Haddock should automatically provide links to all instances exported from the module that are either (1) instances for datatypes or classes exported by the module, or (2) orphan (i.e. not defined in the same module as either the class or the datatype). (It would be too tedious to list *all* exported instances, but luckily it's not necessary for completeness.) -Isaac
Isaac Dupree wrote:
Sean Leather wrote:
I have a module A that re-exports module B, and module B contains only
class instances. Since I'm using -Wall, I get this warning about module B exporting nothing. Is there a way to disable this particular warning, since it is unnecessary in this case? No mailing list messages or GHC documentation has told me what to do.
Well, the warning is right that you don't need to re-export module B: instances are implicitly exported. So you could just remove the export of "module B", unless there's a reason to export it (such as, you might add some exported functions or data types to it later)
Hmm, the disappointing result of removing module B from the export list is that now it doesn't show up in the Haddock-generated documentation for module A. Not that there was anything specific in B to document, because it's only instances. But I do want the user to know that importing A also imports B. Sigh... I suppose there's CPP if I really want it.
So, I tried to do the above with CPP, and I can't get Haddock to recognize that it should list this. Here's what it looks like: module A ( module Z, #ifdef __HADDOCK__ module B #endif ) where ... I added "extensions: CPP" to the .cabal file as I saw instructed in some Cabal thread from long ago. Building works such that I don't get the warning, but "cabal haddock" just acts as if it doesn't recognize __HADDOCK__. Assuming I'm not doing anything wrong, this might be a Cabal problem. You could put a link to the module in the intro-documentation that comes
before the export list, possibly in a sentence saying e.g. "deliberately exports instances from @module B@" (except I've forgotten Haddock syntax and might have used it wrong there :-)
Yep, that is an option. I noticed it in the documentation for another package, the name of which escapes me right now. It's an interesting use-case though. I wonder if Haddock should
automatically provide links to all instances exported from the module that are either (1) instances for datatypes or classes exported by the module, or (2) orphan (i.e. not defined in the same module as either the class or the datatype). (It would be too tedious to list *all* exported instances, but luckily it's not necessary for completeness.)
Yeah, I think instances should be documented in general. But, I agree with Ross in the previous thread, that's a different story. Sean
On Thu, Aug 14, 2008 at 08:00:25PM +0200, Sean Leather wrote:
Well, the warning is right that you don't need to re-export module B: instances are implicitly exported. So you could just remove the export of "module B", unless there's a reason to export it (such as, you might add some exported functions or data types to it later)
Hmm, the disappointing result of removing module B from the export list is that now it doesn't show up in the Haddock-generated documentation for module A. Not that there was anything specific in B to document, because it's only instances. But I do want the user to know that importing A also imports B. Sigh... I suppose there's CPP if I really want it.
That shouldn't be necessary. Because instances are implicitly exported and imported, you'll really want to avoid orphan instances, so that the user can be sure that if both the class and the data type are in scope, so is the instance. But then the instance will be listed under both the class and the type in the Haddock documentation. It won't matter where the instance was defined, just as it doesn't matter where other stuff is defined, just where it is in scope. Unfortunately Haddock does not allow doc comments to be attached to instances, but that's independent of whether the defining module is shown.
Ross Paterson wrote:
On Thu, Aug 14, 2008 at 08:00:25PM +0200, Sean Leather wrote:
Well, the warning is right that you don't need to re-export module B: instances are implicitly exported. So you could just remove the
export of
"module B", unless there's a reason to export it (such as, you might
add
some exported functions or data types to it later)
Hmm, the disappointing result of removing module B from the export list is that now it doesn't show up in the Haddock-generated documentation for module A. Not that there was anything specific in B to document, because it's only instances. But I do want the user to know that importing A also imports B. Sigh... I suppose there's CPP if I really want it.
That shouldn't be necessary. Because instances are implicitly exported and imported, you'll really want to avoid orphan instances, so that the user can be sure that if both the class and the data type are in scope, so is the instance. But then the instance will be listed under both the class and the type in the Haddock documentation. It won't matter where the instance was defined, just as it doesn't matter where other stuff is defined, just where it is in scope.
In my case, it does matter where instances are in scope. My library requires orphan instances by design. If the programmer imports the top-level module, then s/he gets a default set of instances. But the programmer has the option to import select modules and get a different set of classes and instances. My goal was to put the default set of instances into a separate module and re-export that from a higher-level module. That way, it is more clearly documented where things are located. Unfortunately Haddock does not allow doc comments to be attached to
instances, but that's independent of whether the defining module is shown.
Agreed. I am getting the impression that it would be nice if there were a lot of things that were more explicit about instances, both in Haskell and in Haddock. Sean
On Fri, Aug 15, 2008 at 02:21:33PM +0200, Sean Leather wrote:
In my case, it does matter where instances are in scope. My library requires orphan instances by design. If the programmer imports the top-level module, then s/he gets a default set of instances. But the programmer has the option to import select modules and get a different set of classes and instances.
With implicit import, it just doesn't work to have different instances in different places. Suppose two modules use your library in the different ways you envisage. Then those modules cannot be used together in the same program. Your library will not be re-usable. I'd recommend seeking alternate forms of parameterization.
Ross Paterson wrote:
On Fri, Aug 15, 2008 at 02:21:33PM +0200, Sean Leather wrote:
In my case, it does matter where instances are in scope. My library requires orphan instances by design. If the programmer imports the top-level module, then s/he gets a default set of instances. But the programmer has the option to import select modules and get a different set of classes and instances.
With implicit import, it just doesn't work to have different instances in different places. Suppose two modules use your library in the different ways you envisage. Then those modules cannot be used together in the same program. Your library will not be re-usable.
It is not true that those modules cannot be used in the same program. It is possibly true that they cannot both be imported by another module. (It depends on how the instances are used.) The issue is not that the library is not re-usable. It's simply a trade-off. One use of the library (the default) allows for simplicity. The second use allows for extensibility and specialization. The latter requires more work, but it is possible. Sean
On Fri, Aug 15, 2008 at 03:09:16PM +0200, Sean Leather wrote:
Ross Paterson wrote: With implicit import, it just doesn't work to have different instances in different places. Suppose two modules use your library in the different ways you envisage. Then those modules cannot be used together in the same program. Your library will not be re-usable.
It is not true that those modules cannot be used in the same program. It is possibly true that they cannot both be imported by another module. (It depends on how the instances are used.)
If they're in the same program, there will be chains of imports from Main to each of them, so Main will implicitly import conflicting instances and will be rejected by the compiler.
Ross Paterson wrote:
On Fri, Aug 15, 2008 at 03:09:16PM +0200, Sean Leather wrote:
Ross Paterson wrote: With implicit import, it just doesn't work to have different instances in different places. Suppose two modules use your library in the different ways you envisage. Then those modules cannot be used together in the same program. Your library will not be re-usable.
It is not true that those modules cannot be used in the same program. It is possibly true that they cannot both be imported by another module. (It depends on how the instances are used.)
If they're in the same program, there will be chains of imports from Main to each of them, so Main will implicitly import conflicting instances and will be rejected by the compiler.
module A where class A t where a :: t module B where import A instance A Int where a = 0 a0 :: Int a0 = a module C where import A instance A Int where a = 1 a1 :: Int a1 = a module Main where import A import B import C main = do putStrLn $ "a0=" ++ show a0 putStrLn $ "a1=" ++ show a1 This works, because of the way the instances are used. While overlapping instances are imported into Main, they are not used in Main. Sean
On Fri, Aug 15, 2008 at 04:17:44PM +0200, Sean Leather wrote:
module A where class A t where a :: t
module B where import A instance A Int where a = 0 a0 :: Int a0 = a
module C where import A instance A Int where a = 1 a1 :: Int a1 = a
module Main where import A import B import C main = do putStrLn $ "a0=" ++ show a0 putStrLn $ "a1=" ++ show a1
This works, because of the way the instances are used. While overlapping instances are imported into Main, they are not used in Main.
Then that is a GHC bug. Haskell 98 Report 4.3.2: "A type may not be declared as an instance of a particular class more than once in the program."
participants (3)
-
Isaac Dupree -
Ross Paterson -
Sean Leather