
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