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

[Chris Kuklewicz]

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