Revamping the module hierarchy (was: ANNOUNCE: OpenGLRaw 1.0.0.0)

[Simon Marlow]

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