Hi
> In fact, one drawback of using a hierarchy is that it does suggest (by way
> of module names) a hierarchy that the code does not have. For example, I
> believe there are going to be cyclic imports between files in different
> subtrees. That may make the situation actually more confusing than it is
> now.
The first use for a module heirarchy is to help beginners make the
module name <-> filename mapping. In this sense, it does no more or
less than the current system, it just helps beginners find files
quickly.
In Hoogle I use the approach that Max suggests, having
Hoogle.DataBase.{TypeSearch,NameSearch,Suggestions...}, and then have
Hoogle.DataBase.All* which imports all the modules, and exports them
all. It works very well for me doing Hoogle work, and it did help me
to structure the code better, or at least make the poor structurings
obvious.
(* Side note: I found it easier to call the module Hoogle.DataBase.All
instead of Hoogle.DataBase so that when working on Hoogle.DataBase all
the relevant files are in the same place)
Thanks
Neil
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
