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