Revamping the module hierarchy (was: ANNOUNCE: OpenGLRaw
marlowsd at gmail.com
Wed Jun 24 06:47:52 EDT 2009
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
- 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).
More information about the Libraries