On 17/06/2009 10:05, Malcolm Wallace wrote:
Wolfgang Jeltsch<g9ks1...@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 librar...@haskell.org)
Cheers,
Simon
_______________________________________________
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
