public/private module sections (was: Haskell-prime Digest, Vol 2, Issue 58)

[kahl at cas.mcmaster.ca]

Bulat.Ziganshin responded to Claus Reinke:
 > 
 > CR> yes, this would add one constraint on where to place definitions. but
 > CR> grouping logically related definitions together is not quite what one 
 > CR> might think anyway: aren't the definitions making up the interface
 > CR> most strongly related, with the others just changeable auxiliaries?
 > 
 > [...]
 >
 > and in order to see map's type or comment when i implement it, i
 > should see to other part of file. i personally prefer to have
 > public/private modifiers on each function and gather interface
 > documentation by tools like haddock

In my personal experience, I have three kinds of Haskell modules:

 1.  Exporting everything
 2.  Exporting almost everything
 3.  Having a designed export interface


I agree with Claus' comment,
understanding it to refer to modules of kind 3.

I also agree with the motivation of Bulat's comment,
and understand it to refer mostly to modules of kind 1.


I found myself striving to eliminate large modules of kind 2,
typically replacing them by a large module of kind 1
which re-exports a small kernel module of kind 3
(or, to be honest, frequently of kind 2).
This method is mostly for statype encapsulation ---
another motivation to have kind 2 modules are auxiliary functions:
I mostly strive to abstract them away
into (kind 1) standard library supplement modules, or keep them local.

Therefore, I essentially do not have large kind 2 modules,
and for each module of kind 3 (or small module of kind 2) in my code base,
I guess I have at least five of kind 1.
(I.e., for each module with an explicit export list, at least five without,
 or with an export list that only adds re-exports of imports.)


Module kind 1 is of course extremely well-served by the option
not to have an explicit export list ---
I may have overlooked something,
but I did not have the impression that anybody wanted to abolish that,


Module kind 3, where we put real thought into design of the interface,
would of course be served better by a more explicit interface syntax
(like ML's signatures, or module types).


Therefore I would propose that we try to get a better
and more conscious feeling of the different module kinds we need supported,
and then optimise the language for each module kind separately
as far as possible.

Do you have or recognise other frequently-used module kinds?
Should we consider collection modules, or, more generally, kind 1 modules
that also re-export imports, as a separate kind?


Wolfram