Re: [Haskell] Re: Top Level

On 17/06/2009 10:05, Malcolm Wallace wrote:

Wolfgang Jeltsch wrote:

...

The Yampa people and I (the Grapefruit maintainer) already agreed to introduce a top-level FRP namespace instead of putting FRP under Control or whatever.

The problem with a top-level namespace like FRP is that it is a cryptic acronym: it means nothing to a novice, and may be easily confused with other acronyms by an expert. I believe top-level names should _at_the_ _very_least_ be minimally descriptive of the category of things that live in it.

So, I'd be fine with Control.Reactive.FRP, Control.Reactive.Yampa, etc, or even just Reactive.Yampa etc.

I think this raises an interesting point. 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. Including non-functionality-related information in module names should only be used to distinguish between multiple implementations of related functionality (e.g. Test.HUnit vs. Test.QuickCheck). That was before Hackage, which has largely taken over the role of helping users discover functionality. Obviously Hackage has a long way to go - it only has rudimentary categories right now, and in the past we've discussed having a more elaborate tagging scheme, but nevertheless Hackage seems like the right place to provide functionality-discovery. Before packages, there was a single module namespace shared by everyone. Now, for better or worse, there is a single package namespace shared by everyone, and the module namespace is essentially a free-for-all. Where does that leave module names? What are the advantages of having a rigidly-defined module hierarchy based on functionality classification? The only reasons I can think of are: * Choosing module names based on some generally agreed-upon guidelines makes it less likely that one package's module names will clash with another. * Packages that are conglomerations of different kinds of functionality (e.g. base) benefit from functionality-based module naming. * Source code doesn't refer to packages, it only refers to module names. So if you're trying to understand a piece of source code, it helps if the module names it imports are descriptive and unique. On the other hand, a module name tells you nothing of the provenance or the version of the module it refers to, so arguably source code without its dependencies is already less than useful. 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. Discuss! (replies set to libraries@haskell.org) Cheers, Simon