Revamping the module hierarchy

[wren ng thornton]

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.

-- 
Live well,
~wren