version comparison functions

version comparison functions

[Juanma Barranquero]

What is this stuff and why it is useful?

2005-08-24  Vinicius Jose Latorre  <viniciusjl@ig.com.br>

	* subr.el (version-separator, version-regexp-alist): New vars used by
	version comparison funs.
	(integer-list-<, integer-list-=, integer-list-<=)
	(integer-list-not-zero): New funs for integer list comparison.
	(version-to-list, version=, version<, version<=): New funs for version
	comparison.

                    /L/e/k/t/u

Re: version comparison functions

[Richard M. Stallman]

version< is useful for comparing version number strings.
I told Vinicius he could install it.

Re: version comparison functions

[Juanma Barranquero]

On 8/26/05, Richard M. Stallman <rms@gnu.org> wrote:

> version< is useful for comparing version number strings.

In the past we've had threads just to decide whether to add or change
tiny things (I fondly remember discussing whether the four or five
different implementations of `time-less-p' scattered there and here
merited being generalized out to a single `time-less-p' and put on
subr.el :).

So I suppose I'm just a bit surprised at the thought of adding two
variables, seven functions and one alias just to do version
comparison. Not even the `integer-list-*' functions are general, as
they consider '(1) and '(1 0) to be equal, which doesn't strike me as
a very common need. They would be better named `version-list-*', IMO.

But I digress...

-- 
                    /L/e/k/t/u

Re: version comparison functions

[Kim F. Storm]

Juanma Barranquero <lekktu@gmail.com> writes:

>> version< is useful for comparing version number strings.

> So I suppose I'm just a bit surprised at the thought of adding two
> variables, seven functions and one alias just to do version
> comparison. Not even the `integer-list-*' functions are general, as
> they consider '(1) and '(1 0) to be equal, which doesn't strike me as
> a very common need. They would be better named `version-list-*', IMO.

I agree -- and I just changed their names accordingly.

I also fixed a bug that caused e.g. (version< "1" "1.0") to trap.

Finally, I changed version= from being an alias for string-equal
to using the provided version-list-= function.

Before my change:

(version< "1" "1.0")
=> nil

(version<= "1" "1.0")
=> t

(version= "1" "1.0")
=> nil


With my change, it gives the logical result.

(version= "1" "1.0")
=> t

I don't know the rationale for aliasing version= to string-equal, but
to me it was logically wrong to do so -- and if someone wants to use
string-equal, they should do so!


BTW, I agree with Juanma that this is hardly the time to add this
stuff...

..but now that it has happened, I think it makes sense for these
functions to accept an optional argument to limit the number of
version string elements to compare.  E.g.

       (version= "22.0.50" "22.0.50.37")    => nil
       (version= "22.0.50.36" "22.0.50.37") => nil

       (version= "22.0.50" "22.0.50.37" 3)    => t
       (version= "22.0.50.36" "22.0.50.37" 3) => t


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: version comparison functions

[Jason Rumney]

Kim F. Storm wrote:

>..but now that it has happened, I think it makes sense for these
>functions to accept an optional argument to limit the number of
>version string elements to compare.  E.g.
>
>       (version= "22.0.50" "22.0.50.37")    => nil
>       (version= "22.0.50.36" "22.0.50.37") => nil
>
>       (version= "22.0.50" "22.0.50.37" 3)    => t
>       (version= "22.0.50.36" "22.0.50.37" 3) => t
>  
>
This may be useful as an addition to a general version number 
comparison, but for Emacs version numbers, I think we should DTRT based 
on the shorter of the two arguments:

(version= "22" "22.0.50.37") => t

Actually, I don't see why you need the second argument at all - won't it 
always be emacs-version you want to compare with?

Re: version comparison functions

[David Kastrup]

Jason Rumney <jasonr@gnu.org> writes:

> Kim F. Storm wrote:
>
>>..but now that it has happened, I think it makes sense for these
>>functions to accept an optional argument to limit the number of
>>version string elements to compare.  E.g.
>>
>>       (version= "22.0.50" "22.0.50.37")    => nil
>>       (version= "22.0.50.36" "22.0.50.37") => nil
>>
>>       (version= "22.0.50" "22.0.50.37" 3)    => t
>>       (version= "22.0.50.36" "22.0.50.37" 3) => t
>>  
>>
> This may be useful as an addition to a general version number
> comparison, but for Emacs version numbers, I think we should DTRT
> based on the shorter of the two arguments:
>
> (version= "22" "22.0.50.37") => t

That would mean
(version= "22" "22.0.50.37") => t
(version= "22" "22.1.50.37") => t
(version= "22.0.50.37" "22.0.50.37") => nil

Not exactly endearing to the average mathematician or logician...

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: version comparison functions

[Michael Welsh Duggan]

Jason Rumney <jasonr@gnu.org> writes:

> Kim F. Storm wrote:
>
>>..but now that it has happened, I think it makes sense for these
>>functions to accept an optional argument to limit the number of
>>version string elements to compare.  E.g.
>>
>>       (version= "22.0.50" "22.0.50.37")    => nil
>>       (version= "22.0.50.36" "22.0.50.37") => nil
>>
>>       (version= "22.0.50" "22.0.50.37" 3)    => t
>>       (version= "22.0.50.36" "22.0.50.37" 3) => t
>>  
>>
> This may be useful as an addition to a general version number 
> comparison, but for Emacs version numbers, I think we should DTRT based 
> on the shorter of the two arguments:
>
> (version= "22" "22.0.50.37") => t
>
> Actually, I don't see why you need the second argument at all - won't it 
> always be emacs-version you want to compare with?

No.  It might be the version of an emacs package (like tramp-version).

-- 
Michael Welsh Duggan
(md5i@cs.cmu.edu)

Re: version comparison functions

[Richard M. Stallman]

    This may be useful as an addition to a general version number 
    comparison, but for Emacs version numbers, I think we should DTRT based 
    on the shorter of the two arguments:

    (version= "22" "22.0.50.37") => t

Actually, version= was not supposed to be installed at all.  It isn't
necessary, since people can use string=.

Re: version comparison functions

[Jason Rumney]

Juanma Barranquero wrote:

>In the past we've had threads just to decide whether to add or change
>tiny things
>
Indeed. In this case, that discussion took place in May 2003.

Re: version comparison functions

[Juanma Barranquero]

On 8/26/05, Jason Rumney <jasonr@gnu.org> wrote:

> Indeed. In this case, that discussion took place in May 2003.

Hardly strange, then, that I didn't know or remembered about it, don't
you think? ,-)

-- 
                    /L/e/k/t/u

Re: version comparison functions

[Richard M. Stallman]

    In the past we've had threads just to decide whether to add or change
    tiny things

Some of those discussions about tiny things are necessary and useful,
but sometimes I think they are unnecessary--and they take time.  I
decided to avoid a discussion for this point because I did not see
a need for one.

Re: version comparison functions

[Kim F. Storm]

"Richard M. Stallman" <rms@gnu.org> writes:

> version< is useful for comparing version number strings.

I doubt it is very useful without any mentioning in NEWS or
the lispref...

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: version comparison functions

[Stefan Monnier]

> version< is useful for comparing version number strings.

How often does that happen?
And for those rare cases where some piece of elisp code uses a version
comparison, how many of those could advantageously use
a feature-test instead?  I thought we'd discussed and rejected such version
comparison functions in the past.


        Stefan

Re: version comparison functions

[Juanma Barranquero]

On 8/26/05, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> How often does that happen?
> And for those rare cases where some piece of elisp code uses a version
> comparison, how many of those could advantageously use
> a feature-test instead?  I thought we'd discussed and rejected such version
> comparison functions in the past.

Yeah. That was my point, too.

-- 
                    /L/e/k/t/u

Re: version comparison functions

[Vinicius Jose Latorre]

Ok, folks, should I remove all version string comparison stuff from subr.el?


Juanma Barranquero wrote:

> On 8/26/05, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
>> How often does that happen?
>> And for those rare cases where some piece of elisp code uses a version
>> comparison, how many of those could advantageously use
>> a feature-test instead? I thought we'd discussed and rejected such 
>> version
>> comparison functions in the past.
>
>
> Yeah. That was my point, too.

Re: version comparison functions

[Juanma Barranquero]

On 8/27/05, Vinicius Jose Latorre <viniciusjl@ig.com.br> wrote:

> Ok, folks, should I remove all version string comparison stuff from subr.el?

I just wondered. Shouldn't we all, at this point, for every new feature?

-- 
                    /L/e/k/t/u