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

[Isaac Dupree]

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