Revamping the module hierarchy
wren ng thornton
wren at community.haskell.org
Sun Jun 21 20:10:40 EDT 2009
Conal Elliott wrote:
> Amen to Iavor's proposal!
> Hierarchical decomposition leads to arbitrary and thus unguessable
> decisions, because many such decompositions are possible. This problem
> nearly always happens, as Clay Shirky illustrates at
> http://www.shirky.com/writings/ontology_overrated.html . Iavor has given
> some examples. Data vs Control provides some more. Another, as Wolfgang
> hinted at, is UI vs Graphics. These two notions overlap, with neither being
> more specific than the other.
> Module hierarchy tries to give ontology and collision-avoidance. Ontology
> is an failure as we've seen (and inevitably so, as Clay Shirky
> demonstrates). Collision-avoidance has failed also, as Iavor pointed out,
> since packages can easily have module name collisions (e.g., I had a
> Data.Fun at one point). However, we already prohibit collisions of package
> names, so we can get module uniqueness by using the package name as the
> top-level portion of every module in a package. Beyond that requirement,
> package implementors can use whatever organzation style they like.
I would like to amend this with the proposal I've been floating around.
In particular, even though the package name/version should be the root
of a global naming scheme, it should be considered orthogonal to how
modules are named from within Haskell code. The grafting mechanism I've
proposed offers one way of taking advantage of that orthogonality.
Both the grafting proposal and the proposal of making the package name
be the root will, ultimately, fall prey to the same problems of
ontology/hierarchy (until we find a better way of naming modules within
Haskell). However, the grafting proposal will delay the inevitable for
longer, since it allows every compilation-unit to define their own
private hierarchy which needs only suffice for their purposes (i.e.
constructing an initial hierarchy for others to manipulate).
To make things more concrete, it's the provenance issue. We don't want
to encode package versions in the within-Haskell module names, for
obvious reasons. Similarly, we don't want to encode the package names.
Over time packages have a tendency to grow and split into multiple
packages, and we don't want code that was valid at minus-epsilon from
the change to break at plus-epsilon when no actual code has changed. And
there are similar issues with merging packages or migrating modules from
one package to another.
More information about the Libraries