Robert Dockins wrote: > > On Mar 19, 2007, at 9:56 AM, Henning Thielemann wrote: > >> >> On Mon, 19 Mar 2007, Fawzi Mohamed wrote: >> >>>> A practice I've seen a lot in small- to mid-sized programs is to have >>>> a Types module that contains definitions of the types used in the >>>> program. >>> >>> ok I will think about it >> >> I'd avoid that and suggest a more decentralized design, where each module >> contributes one main type and according functions. > > I'd just like to mention that I've used the central "Types" module > myself on occasion. The main reason is to avoid the need for mutually > recursive modules, and not because its a particularly nice design. I > try to arrange the user-visible API around some coherent organizing > principle, such as the one Henning proposes, but that sometimes leads to > module dependency cycles; factoring out a Types module is one way to > break the cycles. > > Rob Dockins
I used a "Types" module for most of the types in the all haskell regex-* backends I wrote. Doing anything else tended to lead to cycles, like Rob mentioned. This seems to be a result of "module/import" being the one-true-and-unique-way to create a namespace combined with almost no support for recursive modules. Thus data types that (indirectly) refer to each other must be in the same namespace. Thus one cannot even have a "all data types go in separate modules" policy. As I write the above, I wonder: if a new variant of "module" that only defines data constructors and types could be created then could compilers support these if they have mutual recursive imports/references? The other alternative being: Make one "Types" module file that has a new variant of "sub-module" that defines module namespaces inside the file. This is much that same as concatenating all the separate type modules into a single file. -- Chris _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
