Re: proposal: in base, for Data.Version, change the meaning of comparisons

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 wrote:

...

I see advantages and disadvantages. Advantages: * matches intuitive understanding of versions * lets us drop trailing zeroes in version numbers

maybe, but the trailing zeroes have some effect so far...

...

Disadvantages: * 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 [1] [] < Version [1,-1] [] True Prelude Data.Version> Version [1,-1] [] < Version [1,0] [] True Prelude Data.Version> Version [1] [] < Version [1,0] [] True #by transitivity; but the proposal would defeat that Actually not if [1,-1] < [1], which would be plausible to be part of the implicit trailing zeroes concept Isaac