Compiler versions
Isaac Jones
ijones at syntaxpolice.org
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 informatik.uni-bremen.de> writes:
(snip)
> 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
More information about the Libraries
mailing list