<div dir="ltr">Isaac Dupree wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Sean Leather wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I have a module A that re-exports module B, and module B contains only<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
class<br>
instances. Since I'm using -Wall, I get this warning about module B<br>
exporting nothing. Is there a way to disable this particular warning,<br>
since<br>
it is unnecessary in this case? No mailing list messages or GHC<br>
documentation has told me what to do.<br>
<br>
</blockquote>
Well, the warning is right that you don't need to re-export module B:<br>
instances are implicitly exported. So you could just remove the export of<br>
"module B", unless there's a reason to export it (such as, you might add<br>
some exported functions or data types to it later)<br>
</blockquote>
<br>
<br>
Hmm, the disappointing result of removing module B from the export list is<br>
that now it doesn't show up in the Haddock-generated documentation for<br>
module A. Not that there was anything specific in B to document, because<br>
it's only instances. But I do want the user to know that importing A also<br>
imports B. Sigh... I suppose there's CPP if I really want it.<br>
</blockquote>
</blockquote><div><br>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:<br><br>module A (<br> module Z,<br>#ifdef __HADDOCK__<br> module B<br>
#endif<br> ) where ...<br><br>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.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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 :-)<br>
</blockquote><div><br>Yep, that is an option. I noticed it in the documentation for another package, the name of which escapes me right now.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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.)<br>
<font color="#888888">
</font></blockquote><div><br>Yeah, I think instances should be documented in general. But, I agree with Ross in the previous thread, that's a different story.<br><br>Sean<br></div></div></div>