Compiler versions

[Malcolm Wallace]

> > 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.

> Perhaps the best choice is to pick a policy that is as unrestrictive as
> possible.

I don't think we need to force a uniform policy.  All we need is those
few constraints in the class definition - namely partial ordering of
versions, printability, and readability.

Regards,
    Malcolm