|Version 3 (modified by malcolm.wallace@…, 8 years ago) (diff)|
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.
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?
- 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.
- maintenance issues with keeping multiple versions of code working
- 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 for discussion of the above points.
3. If so, should they support multiple versions in the same program?
(There are issues here about binary compatibility across different versions of the same compiler.)
- 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 SolveThePackageAbstractionProblem?
- 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
- 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.