proposal: in base, for Data.Version,
change the meaning of comparisons
isaacdupree at charter.net
Fri Oct 26 10:29:36 EDT 2007
Malcolm Wallace wrote:
>>> Proposal: that values of the type Data.Version.Version should
>>> compare equal, by ignoring trailing zeros.
>>> Thus 1.2.0 == 1.2, rather than 1.2.0 > 1.2
> Simon Marlow <simonmarhaskell at gmail.com> wrote:
>> I see advantages and disadvantages.
>> * matches intuitive understanding of versions
>> * lets us drop trailing zeroes in version numbers
maybe, but the trailing zeroes have some effect so far...
>> * version ordering is slightly harder to explain
> Pretty much, yes. Although arguably the disadvantage is not so bad,
> since currently one has to explain why 1.2.0 is _not_ the same as 1.2.
* it means (==) is not extensional equality for Versions (e.g. (vA == vB
&& not (show vA == show vB))... then again, this is already true if
versionTags is used for anything.
(show version), and especially the appending-the-date, depend on how
many trailing zeroes are in a particular version
so it is likely to be ill-defined, if versions are used as Map keys,
which one is stored as the key... not too bad, but people tend to think
of (==) as extensional equality most of the time, I think
>> Is there a precedent anywhere else for doing this?
okay, the precedent you demonstrated seems like an advantage
if we do this, we should find a way not to depend on the number of
trailing zeroes for anything?
note that, version-wise, unless we imagine (rightly enough) that
negative version numbers are forbidden, this would make Version not even
obey the Ord laws; currently
Prelude Data.Version> Version   < Version [1,-1] 
Prelude Data.Version> Version [1,-1]  < Version [1,0] 
Prelude Data.Version> Version   < Version [1,0] 
True #by transitivity; but the proposal would defeat that
Actually not if [1,-1] < , which would be plausible to be part of the
implicit trailing zeroes concept
More information about the Libraries