On 22/06/2009 00:21, 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.
On the other hand, having module names be independent of package names means that - we can have multiple packages that implement the same API, making it easy to compile code against different implementations of an API - we can reorganise the contents of package without requiring any changes to source code, only .cabal files A package conflates lots of things - perhaps too many things. But one thing a package is useful for is to behave like an interface; a package is an API. I've been thinking that we should make it easier to construct packages that are nothing but views on other packages, i.e. a pure interface. Right now it's possible to do this (this is how we implement base3-compat), but it's not convenient. A view has the advantage that it can hide parts of the packages it depends on, and can hence change less frequently. So by depending on a view you get a more robust dependency. We're considering doing something like this for the base package in GHC: base-internals would be what we currently call the base package, and "base" would be a view on that that hides the GHC.* modules, and hence doesn't change its API as often. (there are various options here, I think Ian is going to outline the proposals soon). Cheers, Simon