
Simon Marlow wrote (snipped):
I agree it's not worth arguing, it's more important to decide whether we can implement Read Version.
Why is the Read instance for Version so important? I don't really see one using it much. The only occasion I can imagine when you would actually want to create a Version value for GHC is when you send a new release out the door.
I don't really the instance of Ord being that important either. What one wants to know is whether (1) version X was released later than some given date; (2) version X is lexicographically subsequent to [sequence of integers] (so GHC 6.02.1 comes after GHC 4.08.1); (3) version X is a subversion of [sequence of integers], as 6.2.1 is a subversion of 6.2; (4) version X has a tag attached meaning "DANGER. Do not use unless your name is Simon".
I see - I assumed you were planning to have Ord and Read instances for Version and compare versions by doing if ghc_version => read "6.2" then ... but you'd do it like this: if branch ghc_version >= [6,2] then ... which is fine. In fact, I think I like yours better :-) I'm not convinced of the need to have a date attached to all versions, though. Under what circumstances do you imagine needing (1) above, where (2) won't do? Cheers, Simon

Simon Marlow wrote (initially quoting me, snipped):
What one wants to know is whether (1) version X was released later than some given date; (2) version X is lexicographically subsequent to [sequence of integers] ... I'm not convinced of the need to have a date attached to all versions, though. Under what circumstances do you imagine needing (1) above, where (2) won't do?
In an ideal world dates wouldn't matter, but in the real world programs bitrot, and a bundle of source code which works with version N of a compiler may very well not work with version N+1. Clock times are useful here because they do not depend on the project. They also cost virtually nothing, since it's easy to put them in automatically when Version values are generated. I've no objection though to having the relevant field in the Version type Maybe ClockTime rather than ClockTime, in which case operation (1) should give an error. On the other hand you could just set the ClockTime value to (error "Sorry, I can't be bothered to figure out the release date") as a way of dealing with historical releases and getting the same effect. But I really think it should at least be possible, indeed the default, for Versions to contain a timestamp.
participants (2)
-
George Russell
-
Simon Marlow