[Haskell] A haddock question

[Benjamin Franksen]

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 
data types).

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.

Cheers,
Ben