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