[Haskell-cafe] what I learnt from my first serious
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
>>> 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