On Mon, Jul 18, 2005 at 07:01:08PM +0200, Henning Thielemann wrote:
On Fri, 15 Jul 2005, Andrew Pimlott wrote:
Even given an ideal implementation (I would add that it should allow multiple modules in one file),
Why?
Mere comfort, given my tools and habits. I sometimes want a new module (say for namespace management), but not a new file (it would be inconvenient or divide logically related pieces). But this leads into a tools war, which I don't want.
I don't find one type or class per module preferable. I think it's usually a false division.
It helped me to decide for divisions early. What do you use as division criterion?
It wasn't my intent to propose one. :-) But probably based on some fuzzy measure of user convenience.
For another, the user will probably have to import several modules, and remember which which module contains a function that operates on multiple types.
Yes, that's the way modularization work. That's not a problem with the T name but general to modularization, isn't it?
When you modularize, you can choose to expose bigger or smaller chunks. Indeed, many libraries (eg, Parsec, System.Posix, WASH CGI) do both, reexporting (parts of) several modules in a single module. Your style tends to imply many small modules, which may not be convenient for the user. As a user, I generally prefer a library exposed as a single module. Especially when I am just learning the library, hunting through several modules is a headache--and the beauty of careful module divisions is lost on me!
When it has only small practical advantages (and some disadvantages).
The big advantage is that you can keep the interfaces of all modules consistent. Ideally you can switch an 'import qualified ... as' statement to a different module which serves the same interface with different implementation. For instance you could switch between matrix implementations based on different back-ends. Though, this is probably better solved with type classes.
I don't see how your style makes it easier to write multiple modules with the same interface. Agreeing on the type name seems no harder than agreeing on the function names. And to the extent that it is "consistent", it seems only a minimal and superficial consistency. I really doubt it is a "big advantage" in practice. Andrew