Compiler versions

Isaac Jones ijones at
Wed Apr 7 11:19:35 EDT 2004

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 <ger at> writes:


> 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)?



More information about the Libraries mailing list