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?
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?
For one, there will be functions that operate on multiple types, so where do you put those?
I try to find out which is the more complex one, which one depends on the other. In this example I consider a matrix as a representation of a linear map (see the long preceding discussion about how matrices can be interpreted :-), where the linear maps operate on vectors. Thus matrices depend on vectors but not vice versa, so I put (basic) matrix-vector operations to the matrix module. More complicated functions can be moved in a separate module.
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 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.