Type prefixes vs. qualification (Was: System.FilePath propsal)

[Henning Thielemann]

On Fri, 29 Oct 2004, Johannes Waldmann wrote:

> A remark on naming: I don't like names like "absolutizePath".
> 
> The "Path" suffix in fact expresses type (resp. module) information,
> and I would think that it is typical for languages
> *without* proper type resp. module system
> to force programmers to simulate them by mere naming conventions.

yep

> So I would suggest to use qualified names (Path.absolutize).

*me too*

> Of course that's seems to be a general problem,
> for instance, with insertFM, lookupFM.
> But then, the FiniteMap module
> is much older than hierachical namespaces.
> But for Paths, the point is designing a new library,
> so we should use the best techniques available.

 I really advise to take a look at Modula-3. There, not only every
function name omits the information of the type, even more each module has
the name of the type it describes and the main type has the name T. In
Modula-3 this convention is essential for template modules. This doesn't
introduce new problems because module names have to be unique. So the user
of a library can choose if he wants to use a short unqualified function
name, some abbreviated module name for qualification or the full module
name. 
 I started to use this style for my Haskell modules, too, e.g. 
  http://cvs.haskell.org/darcs/numericprelude/physunit/PhysicalValue.hs
 I'm still uncertain what identifier to use for constructors and type
classes.

> In fact it's only one technique, qualified names -
> the other candidate would be a type system
> that allows static overloading...

If you don't propose the way C++ does it ... :-) But how can overloading
be cleaner than type classes?