
I prefer George's idea of an abstract version type which is an instance of Show, Read and Ord. I'd probably also add majorVersion and minorVersion functions, which could return perhaps the same abstract type.
Sounds good to me.
Using an abstract version type seems to be the best choice for the reasons you give. However, there's a compromise here:
- If you have an abstract version type for the version of entity X, then you need one version type for each X, because they have different versioning policies. (e.g. we can't use the same version type for the version of the Haskell language and the version of the compiler, or versions of libraries).
Can't we solve that problem with classes?
class (Show a, Read a, Ord a) => Version a where version :: a majorVersion :: a -> a minorVersion :: a -> a
Each entity (language, compiler, library) can indeed define its own versioning type and policy, with this abstract interface. It just needs to publish the name of the concrete type that implements it.
There isn't really a "problem" here, just that having lots of different version types might be unnecessary. I'm not sure that having a unified majorVersion/minorVersion interface buys very much - it implies a kind of binary tree structure to versions, but then I have to say how that is overlaid on the actual structure of each version type, and what it means to compose majorVersion/minorVersion. What would you use 'version' for, BTW? For packages at least, we have to pick a single versioning policy for all packages so that the library infrastructure can manage dependencies without having to know a separate versioning policy for each individual package. Ok, well it's not that big a deal. I guess we could have module System.Info -- or something data ImplementationVersion -- instacne Eq, Ord, Read, Show implementationVersion :: ImplementationVersion data HaskellVersion -- instance Eq, Ord, Read, Show haskellVersion :: HaskellVersion haskellExtensions :: [Extension] and then have a separate PackageVersion type for packages. I'll probably re-use the PackageVersion type for GHC's version. Cheers, Simon
participants (1)
-
Simon Marlow