[Haskell] Re: Top Level

[Malcolm Wallace]

> When we first started using
> hierarchical module names, we established a guiding principle: that
> the  module name should reflect functionality first, so that the
> hierarchy  can help you to find the functionality you're looking for. 

I think the principle of describing functionality still holds good, and
not merely for discovery.  If everyone *really* called their modules by
names like Arbitrary.Foo, Bar.Wibble, My.Utils, Other.Misc, etc, then
having a hierarchy would indeed be totally useless.  But in fact
everyone does still attempt to give meaningful descriptive names to the
leaf modules in the hierarchy, e.g. ...OpenGL.Shaders, ...OpenGL.Points,
...OpenGL.Framebuffer.

If the leaf nodes continue to have descriptive names, then why not the
roots?

> What are the advantages of having a  rigidly-defined module hierarchy
> based on functionality classification? 
>   The only reasons I can think of are:

And you proceed to list three very good reasons.  Since the proposal to
drop meaningful description from the hierarchy is a unforced change,
perhaps someone would like to enumerate the disadvantages of the current
scheme, and the advantages of the proposed change.

So far, I have seen

   * The current names are long.  (This is a physical disadvantage for
     the author who needs to exercise their fingers more, but is a
     cognitive advantage for the reader, who needs to think less.)

   * It is tricky to think of the right category.  (I agree that "the"
     right category might not exist, but surely *some* relevant
     descriptive category is better than no category at all.)

> So why shouldn't OpenGL be naming its modules OpenGL.*, rather than 
> Graphics.Rendering.OpenGL.*?  Personally, I can't think of any 
> sufficiently compelling reasons any more.

The OpenGL example is quite a good one.  People who know what the
acronym means, understand at a glance that this hierarchy is about
graphical rendering in 2D and 3D.  Someone who does not know the meaning
of the acronym will need to reach for Google.  Because most of us
programmers are very familiar with the name, we are blind to the
potential for puzzlement to others.  In this case, Google will help
instantly because OpenGL is extremely widely used, and not just in
Haskell.  But there are many package names that are cryptic, far
from unique, and Google is no help.

If you don't believe me, here is a quick quiz.  Guess at a glance what
general category of functionality is provided by each of the following
package names (taken from hackage).

    hgal
    hmm
    iff
    fec
    scc
    fst
    hybrid
    only
    lax
    tfp
    witness
    thrist
    vacuum
    mps
    alloy
    cap

This is a quiz you can mark yourself.  So how many did you get right
(with the help of Google) *before* you looked at hackage?  Now imagine
that all packages provided this kind of naming scheme as the top-level
roots of their contents.

If you are an author of any of the above packages, please don't
misunderstand me - I am not criticising the package-names at all.  It is
difficult to invent unique searchable identifiers that also immediately
convey meaning.  What I am saying is that, because of this difficulty,
we need to see more than the mere package-name in source code that
depends on it.  Simple descriptive words in the hierarchy are just that
- simple and descriptive.

Regards,
    Malcolm