[Haskell] Re: Top Level

[Simon Marlow]

On 17/06/2009 10:05, Malcolm Wallace wrote:
> Wolfgang Jeltsch<g9ks157k at acme.softbase.org>  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 at haskell.org)

Cheers,
	Simon