FWIW, I think that the LIP can indeed use such a thing. A library can
indicate what versions of a compiler it is dependent upon, and check
that in a test suite, for instance. I can't think of a lot of other
uses offhand...
George Russell
Then a minimal interface for deconstructing Versions might be:
data Version -- abstract
name :: Version -> String -- "GHC", "Hugs", "FFI" for example. version :: Version -> [Int] -- major version would be 0th element, and so on. -- Then I can do (if version compilerVersion >= [6,2,1]) or -- (if take 2 (version compilerVersion) == [6,2]) timestamp :: ClockTime -- better than CalendarTime in my opinion.
and perhaps
tags :: Version -> [String] -- miscellaneous other unspecified qualifiers, for example -- "hacked-for-windows", "experimental" and so on.
The library infrastructure project already implements a basic Distribution.Version type (which I hope will become a standard). It only has dates and basic numeric versioning, along with a variety of ways to parse dates. (I had suggested a while ago that someone should help me implement more complex versions and version string parsing; that's a non-critical-path job that I can easily delegate.) Debian has some kind of rules for this that might be good to base the implementation on. Here's what we have right now: data Version = DateVersion {versionYear :: Integer, versionMonth :: Month, versionDay :: Integer} | NumberedVersion {versionMajor :: Integer, versionMinor :: Integer, versionPatchLevel :: Integer} | NoVersion deriving (Read, Show, Eq, Ord) I like the tags idea a lot. I don't know if your "version" function will work for something like hugs with date-based versions, though it's probably better than my NumberedVersion. I was thinking we'd have a handful of other pre-set versions, along with ways to compare them, and maybe a catchall "OtherVersion String" type. It should definitely implement Ord and Eq, but what should we do if someone tries to compare a DateVersion with a NumberedVersion, for instance? This could possibly happen if a project changed their versioning scheme. Maybe Version should be a typeclass where we provide a handful of defaults like DateVersion and NumberedVersion, and each type will have to provide a 'canonicalize' function much like your "version" function (actually, maybe Ord is good enough)? peace, isaac