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

[Henning Thielemann]

On Thu, 14 Jul 2005, Andrew Pimlott wrote:

> I would like to bristle mildly against the style of using Vector.T to
> represent the vector type.  The reasons are 1) it is cryptic to those
> not used to the convention;

What does this tell about the quality of the concept?

> 2) enshrining one-type-per-module in the naming convention is not IMO
> justified, and may prove limiting;

Other languages like Modula-3 and Oberon do it with great success. The
limit in Haskell is that most compilers don't conform to the Haskell 98
report which allows mutually recursive modules. But I think the compilers
should allow them instead of forcing users to put many type and class
definitions into one module.

> 3) it doesn't work out well when you import a module that reexports
> Vector.

Reexporting is only necessary for unqualified naming style.

Vector.T is just the consequence of removing type-related prefixes from
all identifiers. If you stick to qualified naming you only need to import
the module once. Otherwise you must import a module twice.

import LinearAlgebra.Vector (Vector)
import qualified LinearAlgebra.Vector as V

With this style importing as Vector is even not possible and you have to
manage two abbreviations of the module.

Setting up one module per data type (there are certainly auxiliary types
which don't need it) allows a very clean and consistent naming style:
 DataType.T       for the main type
 DataType.from*   for conversions to that type
 DataType.to*     for conversions into other types
 DataType.*       for other functions related to that type
  It also answers the question whether the module name should be in
singular or in plural form.

> I would say leave it Vector.Vector.  Then the user may import the module
> unqualified, or qualified with an abbreviation like V,
> define his own
> synonym ("type Vector = Vector.Vector"),

What about

import qualified LinearAlgebra.Vector as V

type Vector = V.T

?

> > 1) If I define
> >
> > foo :: Vector.T a -> Matrix.T a
> >
> > Haddock (version 0.6) shows just this:
> >
> > foo :: T a -> T a
>
> I think this is evidence that trying to treat the "primary type" as a
> special case in naming creates more annoyances than it eliminates.

Haddock could adapt the type synonymes that are used in the signatures, or
if it shall make the type names more uniform it could look how the modules
are imported. That is, if a module is imported qualified the type should
be shown qualified with the proposed abbreviation. Following the hyperlink
of the type the user can check what the abbreviated module name means.