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

[Andrew Pimlott]

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