[Haskell] A haddock question
benjamin.franksen at bessy.de
Mon Oct 10 09:28:18 EDT 2005
On Monday 10 October 2005 14:06, Simon Marlow wrote:
> On 10 October 2005 12:44, Benjamin Franksen wrote:
> > I have a module with a public class plus some instances for public
> > data types. In addition, I use this class inside another module
> > where I declare local (module private) data types and make them
> > instances of the class. I had expected that haddock (I am using
> > 0.7) will list in the documentation only instances of data types
> > that are exported, but instead all instances are listed.
> > Is there a way to persuade haddock to list only instances of data
> > types that are actually visible to the user?
> Haddock's support for instances is somewhat braindead - it just
> reports all the instances it can find for a given class in the entire
> set of modules it is processing. In particular, Haddock makes no
> attempt to tell you how to bring these instances into scope: they
> might not be available from the module that exports the class, or the
> type(s), involved in the instance.
> Haskell makes this quite hard: an instance is available if it is
> provided by the transitive closure of an imported module. We clearly
> don't want to report all the available instances in every module's
> documentation, however. We probably don't want to document every
> module from which an instance is available either. Nevertheless,
> doing one of these two would be "correct". I'm open to suggestions.
> Benjamin: your example is probably more simple, Haddock probably just
> shouldn't be exposing those instances if they refer to non-exported
> types, I just wanted to point out the more general problem.
Yes, I can see that the general problem is hard to solve. I don't have
any suggestions how to change the haddock behavior with instances in
general (i.e apart from fixing the obvious bug regarding non-exported
One could even argue that haddock isn't the right place to provide a
solution and that instead the language itself should be fixed. I know
this problem is even harder to solve. To make things worse, I don't
even have a concrete proposal for how to do this and still enjoy all
the nice features Haskell's type classes provide.
But since you brought up the general issue, let me just point out, that
the interaction between type classes and the module system is arguably
the most problematic aspect of Haskell as it stands.
As a programmer (I am not a language designer), this is the point I most
often stumble upon. IMO, Haskell's module system is just a bit too weak
for "programming in the large". While type classes (with the usual
extensions) seem to provide a lot more flexibility and generality, they
are burdened with their unfortunate interaction with the module system.
Don't get me wrong: Of course it is possible to program large systems in
Haskell (witness ghc and a growing number of medium and large size
projects). It is just that many of Haskell's great advantages when
"programming in the small" do not, IMO, appropriately scale to large
systems. Witness to this is the still missing "grand unified data
structure library": The problem here is /not/ that there don't exist
good implementations. The problem is how to integrate all of them into
a common framework, with minimal redundancy between interfaces, and a
maximum of re-use. A related problem is Haskell's weak support for
abstract data types, at least when constrasted with the ease which with
concrete data types can be craeted and used.
I think, this is /the/ most important point that should be addressed in
some future Haskell2 standard. I vaguely imagine some kind of
unification of the concepts type class/instance and module into a new
entity that enables the programmer to talk about interfaces and their
implementation and at the same time control how names are re-used on
the global level (and, ideally, enable some sort of pattern-matching on
abstract data types). I have read about proposals to allow 'named' or
'scoped' instances and I believe that there are some interesting ideas.
Maybe someone with the right education and experience in language/type
system design should review such proposals and see if some coherent
whole can be made out of them.
More information about the Haskell