Simon Marlow wrote:

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.

If everyone does that, it will flatten the Haddocks tree into one huge list. Some people told me they already use only textual search to navigate Haddocks, but I find the structure very helpful, including the higher-level names that hint at functionality. All of the other changes suggested in this thread would improve the usability of the Haddocks tree, provided that we standardize on them. But if everyone has their own idea about how to classify functionality, we're back to the same problem. Regards, Yitz

Am Donnerstag, 18. Juni 2009 18:20 schrieb Maurí­cio:

It's good that everyone have their own idea on classification. That's how we can converge to good for all classification as time passes. What would be nice is to have the proper tools to easily reorganize that hierarchy as we wish.

Very good point! Best wishes, Wolfgang

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