[Haskell-cafe] Re: Module.T naming style

[Henning Thielemann]

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.