[Haskell-cafe] what I learnt from my first serious haskell programm

Chris Kuklewicz haskell at list.mightyreason.com
Mon Mar 19 11:33:54 EDT 2007

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"

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.


More information about the Haskell-Cafe mailing list