library-versioning.md

+## Library Versioning
+
+
+This page is intended to be a summary of the current state of the discussion relating to library versioning.  It's a complicated topic, nothing is clear-cut, and many of the issues affect each other, so I'll try to lay things out as clearly as possible and identify interdependencies where possible.
+
+
+Issues:
+
+### 1. Should there be a fixed set of Haskell' library modules?
+
+
+By this we mean should we require that a compiler claiming to support Haskell' also provides a set of libraries conforming exactly to a published specification.
+
+
+The alternative is to have an evolving library specification, with versioned fixed points.  Compilers would be required to support one or more versions of the specification, and to say which.
+
+### 2. Should compilers provide multiple versions of libraries?
+
+
+Pros:
+
+- would allow compilers to both support code that assumes
+  fixed standardised libraries, while also providing improved versions
+  of libraries
+
+- compilers already provide both Haskell 98 modules and improved
+  hierarchical libraries.
+
+
+Cons:
+
+- maintenance issues with keeping multiple versions of code working
+
+- complexity
+
+- it might not be necessary given suitable development policies
+
+- several other languages seem to manage fine without it (Perl, Python)
+
+
+See [ John Goerzen's message](http://haskell.org/mailman/private/haskell-prime-private/2005-November/000058.html) for discussion of the above points.
+
+### 3. If so, should they support multiple versions in the same program?
+
+
+Pros:
+
+- if we want to move in a direction where less recompilation is required
+  when upgrading compilers and libraries, perhaps using dynamic/shared libraries,
+  we must allow multiple versions to coexist (or allow rebinding to new versions,
+  eg. .NET does both, it has config files to say where rebinding is allowed).
+
+### 4. Should we solve the package abstraction problem as per [ Simon's message](http://haskell.org/mailman/private/haskell-prime-private/2005-December/000065.html)
+
+
+Pros:
+
+- lets us do (2) & (3)
+- it fixes an abstraction problem with packages as they stand
+- it's very similar to what .NET does (assembly==package, namespace==module).
+- it would let us do clever stuff like grafting modules into the hierarchy
+- John M is planning to do it in jhc anyway
+
+
+Cons:
+
+- it's a change to the language, albeit a minor one.  The language specification
+  must mention that a module identity is composed of a package name and a module name,
+  and the compilation system provides some mechanism by which module names are associated
+  with package names within a module.
+
+- we might be able to get away without it (see (1))
+
+- whole program compilers (eg. Hugs) are even less likely to need it, because source
+  dependencies are less rigid than binary dependencies.