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