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 _______________________________________________ Haskell mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell
