Re: master 71783e9: Add the string-numeric-lessp function

Re: master 71783e9: Add the string-numeric-lessp function

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

Ok, this is now implemented:

> +DEFUN ("string-numeric-lessp", Fstring_numeric_lessp,

Replete with tests.  Feel free to change the name, implementation, or
anything else.  :-)

Particularly this:

> +      /* If we're still in a number, add it to the sum and continue. */
> +      /* FIXME: Integer overflow? */
> +      if (c >= '0' && c <= '9')
> +	{
> +	  number = number * 10;
> +	  number += c - '0';
> +	  (*isp)++;
> +	  (*isp_byte) += chlen;
> +	}
> +      else
> +	break;
> +    }

There has to be a simple way to do that check...  hm...  I see that
`string-to-number' uses strtoumax...  Hm...  perhaps I can rewrite this
function to use that instead...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master 71783e9: Add the string-numeric-lessp function

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> There has to be a simple way to do that check...  hm...  I see that
> `string-to-number' uses strtoumax...  Hm...  perhaps I can rewrite this
> function to use that instead...

The code almost got simpler, even.  `string-numeric-lessp' now reverts
to calling `string-lessp' if any of the embedded numbers overflow
size_t.  I think that should be OK for any real world usages...  I mean,
even that could be fixed if we want to be really picky, but I'm not sure
it's worth it.

(The fix would be: If the numerical stretches are of unequal length,
then obviously the shorter one is smaller than the longer.  If they're
of equal length, then we can just compare the numerical stretches
lexicographically.  So we don't really really need to convert anything
to numbers, anyway...)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

RE: master 71783e9: Add the string-numeric-lessp function

[Stephan Mueller]

Lars Ingebrigtsen <larsi@gnus.org> writes:

" The code almost got simpler, even.  `string-numeric-lessp' now reverts
" to calling `string-lessp' if any of the embedded numbers overflow
" size_t.  I think that should be OK for any real world usages...  I mean,
" even that could be fixed if we want to be really picky, but I'm not sure
" it's worth it.

" (The fix would be: If the numerical stretches are of unequal length,
" then obviously the shorter one is smaller than the longer.  If they're
" of equal length, then we can just compare the numerical stretches
" lexicographically.  So we don't really really need to convert anything
" to numbers, anyway...)

Given you're in the code anyway, and have the fix worked out, I'd
be inclined to make the fix.  But the fix might need a fix: what if the
longer one starts with zeros?

stephan();

Re: master 71783e9: Add the string-numeric-lessp function

[Lars Ingebrigtsen]

Stephan Mueller <Stephan.Mueller@microsoft.com> writes:

> Given you're in the code anyway, and have the fix worked out, I'd
> be inclined to make the fix.  But the fix might need a fix: what if the
> longer one starts with zeros?

Oh, that's true...  it should skip leading zeroes.

Yeah, I'll do the fix.  I think the code will perhaps be even simpler
(and shorter) then.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master 71783e9: Add the string-numeric-lessp function

[Yuri Khan]

On Sun, Feb 21, 2016 at 4:02 PM, Lars Ingebrigtsen <larsi@gnus.org> wrote:

> Oh, that's true...  it should skip leading zeroes.

Skipping zeroes will make strings that differ only in the number of
leading zeros (e.g. 001 and 01) equivalent under that sorting order.
Are you okay with that?

Re: master 71783e9: Add the string-numeric-lessp function

[Lars Ingebrigtsen]

Yuri Khan <yuri.v.khan@gmail.com> writes:

> Skipping zeroes will make strings that differ only in the number of
> leading zeros (e.g. 001 and 01) equivalent under that sorting order.
> Are you okay with that?

Yeah, I think those should be equivalent.  If you have a directory with
foo003.png and foo1.png, I would expect the latter to be sorted before
the former.  I think.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master 71783e9: Add the string-numeric-lessp function

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Skipping zeroes will make strings that differ only in the number of
  > leading zeros (e.g. 001 and 01) equivalent under that sorting order.
  > Are you okay with that?

001 and 01 should both sort between 0 and 2, but they should not be
equivalent.  They should have some defined order.

I think that 01 should be less than 001, but I don't insist.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: master 71783e9: Add the string-numeric-lessp function

[Paul Eggert]

Lars Ingebrigtsen wrote:
> Feel free to change the name, implementation, or
> anything else.  :-)

Thanks, I did that.  The idea of my followup is to use the same algorithm that 
GNU ls -v does, rather than invent yet another file name comparison algorithm. 
This should also handle very long integers correctly.  I also changed the name 
to be more like the names used elsewhere.  Please feel free to revert.

Re: master 71783e9: Add the string-numeric-lessp function

[Andy Moreton]

On Sun 21 Feb 2016, Paul Eggert wrote:

> Lars Ingebrigtsen wrote:
>> Feel free to change the name, implementation, or
>> anything else.  :-)
>
> Thanks, I did that.  The idea of my followup is to use the same algorithm that
> GNU ls -v does, rather than invent yet another file name comparison algorithm.
> This should also handle very long integers correctly.  I also changed the name
> to be more like the names used elsewhere.  Please feel free to revert.

Paul, your patch using the gnulib filevercmp function also needs an
update to nt/gnulib.mk to keep the Windows builds working.

fns.o: In function `Fstring_version_lessp':
C:\emacs\git\emacs\master\obj-mingw64\src/../../src/fns.c:364: undefined reference to `filevercmp'
C:\emacs\git\emacs\master\obj-mingw64\src/../../src/fns.c:364:(.text+0x10a2): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `filevercmp'

This seems to work:

diff --git a/nt/gnulib.mk b/nt/gnulib.mk
index 6884bf9..a1d207e 100644
--- a/nt/gnulib.mk
+++ b/nt/gnulib.mk
@@ -334,6 +334,14 @@ EXTRA_DIST += filemode.h

 ## end   gnulib module filemode

+## begin gnulib module filevercmp
+
+libgnu_a_SOURCES += filevercmp.c
+
+EXTRA_DIST += filevercmp.h
+
+## end   gnulib module filevercmp
+
 ## begin gnulib module fpending


After applying that, master bootstraps for 64bit mingw64 again.

    AndyM

Re: master 71783e9: Add the string-numeric-lessp function

[Paul Eggert]

Andy Moreton wrote:

> +libgnu_a_SOURCES += filevercmp.c
> +
> +EXTRA_DIST += filevercmp.h

Thanks, I added that to master. Someday nt/gnulib.mk should be built 
automatically, as lib/gnulib.mk is ...

Re: master 71783e9: Add the string-numeric-lessp function

[Eli Zaretskii]

> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Sun, 21 Feb 2016 20:01:57 -0800
> 
> Andy Moreton wrote:
> 
> > +libgnu_a_SOURCES += filevercmp.c
> > +
> > +EXTRA_DIST += filevercmp.h
> 
> Thanks, I added that to master. Someday nt/gnulib.mk should be built 
> automatically, as lib/gnulib.mk is ...

Indeed.  Patches to that effect will be most welcome.

Re: master 71783e9: Add the string-numeric-lessp function

[Lars Ingebrigtsen]

Paul Eggert <eggert@cs.ucla.edu> writes:

> Thanks, I did that.  The idea of my followup is to use the same
> algorithm that GNU ls -v does, rather than invent yet another file
> name comparison algorithm. This should also handle very long integers
> correctly.  I also changed the name to be more like the names used
> elsewhere.  Please feel free to revert.

Looks nice, but I don't think that's a very good function name.  It
sounds like something that is only meant to be used for version strings,
instead of something that happens to work on version strings as well..

And is this supposed to be this way?

(string-version-lessp "foo001.png" "foo1.png")
=> t

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master 71783e9: Add the string-numeric-lessp function

[Paul Eggert]

Lars Ingebrigtsen wrote:
> Looks nice, but I don't think that's a very good function name.  It
> sounds like something that is only meant to be used for version strings,
> instead of something that happens to work on version strings as well..

Not quite sure I'm following. Every string is a version string.

The function name was inspired by glibc's strverscmp; see:

http://www.gnu.org/software/libc/manual/html_node/String_002fArray-Comparison.html#index-strverscmp

Please feel free to change the name.


> And is this supposed to be this way?
>
> (string-version-lessp "foo001.png" "foo1.png")

Yes, if the version numbers and everything else result in a tie, it falls back 
on straight lexicographic comparison. Having the function be anything other than 
a total order would cause problems in sorting functions that use it to compare.


Oh, and in response to one of your other questions: this function should be 
useful for package versions as well as file names. For example, I recently 
updated my libc-bin version on Ubuntu from 2.21-0ubuntu4 to 2.21-0ubuntu4.1 as 
part of the getaddrinfo security update.

Re: master 71783e9: Add the string-numeric-lessp function

[Lars Ingebrigtsen]

Paul Eggert <eggert@cs.ucla.edu> writes:

> Not quite sure I'm following. Every string is a version string.

I don't think I agree with that.  All version strings are strings,
though.

>> And is this supposed to be this way?
>>
>> (string-version-lessp "foo001.png" "foo1.png")
>
> Yes, if the version numbers and everything else result in a tie, it
> falls back on straight lexicographic comparison. Having the function
> be anything other than a total order would cause problems in sorting
> functions that use it to compare.

That sounds fine for version numbers, but is not what we want when
sorting file names, I think.

> Oh, and in response to one of your other questions: this function
> should be useful for package versions as well as file names. For
> example, I recently updated my libc-bin version on Ubuntu from
> 2.21-0ubuntu4 to 2.21-0ubuntu4.1 as part of the getaddrinfo security
> update.

I don't think that's something our numerical string comparison function
should be doing.  This version string thing sounds very much geared
towards version strings, and that's fine.  Using that function for
anything else seems increasingly odd.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master 71783e9: Add the string-numeric-lessp function

[Paul Eggert]

Lars Ingebrigtsen wrote:

> I don't think that's something our numerical string comparison function
> should be doing.

Again, I'm not sure I'm following. The two strings "2.21-0ubuntu4" and 
"2.21-0ubuntu4.1" are identical except the latter has ".1" appended. Shouldn't 
almost any sane kind of string comparison consider the shorter to be less than 
the longer?

If only some strings are valid for comparison, I suppose the comparison function 
could be a partial function, e.g., it could signal an error when given a string 
that it doesn't think has a valid format. This of course could be done, but it 
makes usage more complicated. For sorting, having comparison functions be total 
functions is much simpler to explain.

At least, that's been the tradition in other GNU tools. GNU ls -v applies the 
string-version-lessp algorithm to every pair of file names that it considers, 
and it works on arbitrary file names. It sounds like you may be thinking of some 
other tradition, although I'm not sure what that tradition would be.

The GNU ls -v approach works well in practice, because people who care about 
version numbers tend to name their files consistently. E.g., they do not put 
files "foo001.png" "foo1.png" in the same directory, because that kind of usage 
would confuse humans no matter what 'ls -v' does.

Re: master 71783e9: Add the string-numeric-lessp function

[Lars Ingebrigtsen]

Paul Eggert <eggert@cs.ucla.edu> writes:

> Lars Ingebrigtsen wrote:
>
>> I don't think that's something our numerical string comparison function
>> should be doing.
>
> Again, I'm not sure I'm following. The two strings "2.21-0ubuntu4" and
> "2.21-0ubuntu4.1" are identical except the latter has ".1"
> appended. Shouldn't almost any sane kind of string comparison consider
> the shorter to be less than the longer?

Oh, I thought you meant that it considered "4.1" to be one unit in the
string, and compared as such.  Sorry for misunderstanding.

> The GNU ls -v approach works well in practice, because people who care
> about version numbers tend to name their files consistently. E.g.,
> they do not put files "foo001.png" "foo1.png" in the same directory,
> because that kind of usage would confuse humans no matter what 'ls -v'
> does.

Yeah, but this isn't about people who care about version numbers.  Its
about real world usage where people just dump a lot of files in a
directory, and expect to be able to find them afterwards.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master 71783e9: Add the string-numeric-lessp function

[Paul Eggert]

Lars Ingebrigtsen wrote:

> this isn't about people who care about version numbers.  Its
> about real world usage where people just dump a lot of files in a
> directory, and expect to be able to find them afterwards.

What can I say? In practice, ls -v seems to work well enough. Perhaps people who 
just dump a lot of files in a directory tend to not care whether foo001.png 
comes before foo1.png so long as they're put close to each other, which they are.

Re: master 71783e9: Add the string-numeric-lessp function

[Juri Linkov]

> At least, that's been the tradition in other GNU tools. GNU ls -v applies
> the string-version-lessp algorithm to every pair of file names that it
> considers, and it works on arbitrary file names. It sounds like you may be
> thinking of some other tradition, although I'm not sure what that tradition
> would be.
>
> The GNU ls -v approach works well in practice, because people who care
> about version numbers tend to name their files consistently. E.g., they do
> not put files "foo001.png" "foo1.png" in the same directory, because that
> kind of usage would confuse humans no matter what 'ls -v' does.

I tried GNU ls -v, but unfortunately it is unusable because of a bug in
GNU ls -v.  It places backup files before original files, e.g. `ls -lv`

-rw-r--r-- 1   158,018 Feb 23 12:01 dired.el
-rw-r--r-- 1   117,286 Feb 23 12:23 dired.elc
-rw-r--r-- 1   110,076 Feb 23 12:01 dired-aux.el
-rw-r--r-- 1    81,586 Feb 23 12:23 dired-aux.elc
-rw-r--r-- 1       253 Feb 23 12:12 dired-loaddefs.el~
-rw-r--r-- 1    20,628 Feb 23 12:12 dired-loaddefs.el
-rw-r--r-- 1    66,420 Feb 23 12:01 dired-x.el
-rw-r--r-- 1    47,687 Feb 23 12:23 dired-x.elc

dired-loaddefs.el~ is sorted to come before dired-loaddefs.el
whereas in `ls -l`

-rw-r--r-- 1   110,076 Feb 23 12:01 dired-aux.el
-rw-r--r-- 1    81,586 Feb 23 12:23 dired-aux.elc
-rw-r--r-- 1   158,018 Feb 23 12:01 dired.el
-rw-r--r-- 1   117,286 Feb 23 12:23 dired.elc
-rw-r--r-- 1    20,628 Feb 23 12:12 dired-loaddefs.el
-rw-r--r-- 1       253 Feb 23 12:12 dired-loaddefs.el~
-rw-r--r-- 1    66,420 Feb 23 12:01 dired-x.el
-rw-r--r-- 1    47,687 Feb 23 12:23 dired-x.elc

dired-loaddefs.el~ naturally comes after dired-loaddefs.el
(as dired.elc naturally comes after dired.el).

The same bug now propagates to ‘string-version-lessp’:

(sort '(
"dired.el"
"dired.elc"
"dired-aux.el"
"dired-aux.elc"
"dired-loaddefs.el"
"dired-loaddefs.el~"
"dired-x.el"
"dired-x.elc"
)
'string-version-lessp)

=>

"dired.el"
"dired.elc"
"dired-aux.el"
"dired-aux.elc"
"dired-loaddefs.el~" <=
"dired-loaddefs.el"  <=
"dired-x.el"
"dired-x.elc"

Re: master 71783e9: Add the string-numeric-lessp function

[Paul Eggert]

Juri Linkov wrote:
> It places backup files before original files

That's a good thing, as it's natural for the older version to come before the 
newer one.

Re: master 71783e9: Add the string-numeric-lessp function

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > It places backup files before original files

  > That's a good thing, as it's natural for the older version to come before the 
  > newer one.

I think it is unnatural and confusing.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: master 71783e9: Add the string-numeric-lessp function

[Lars Magne Ingebrigtsen]

Paul Eggert <eggert@cs.ucla.edu> writes:

> That's a good thing, as it's natural for the older version to come
> before the newer one.

And that's another reason why we shouldn't be using "version" sorting to
sort file names.  Nobody wants that.  Except people who are sorting
versions of software packages.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master 71783e9: Add the string-numeric-lessp function

[Juri Linkov]

>> That's a good thing, as it's natural for the older version to come
>> before the newer one.
>
> And that's another reason why we shouldn't be using "version" sorting to
> sort file names.  Nobody wants that.  Except people who are sorting
> versions of software packages.

Actually I see no more problems with the current version sorting
other than discovered weirdness of sorting for single backups.

Re: master 71783e9: Add the string-numeric-lessp function

[Juri Linkov]

>> It places backup files before original files
>
> That's a good thing, as it's natural for the older version to come before
> the newer one.

Still this is the weirdest sorting order that I've ever seen
where single backups come before, but numbered backups after:

  -rw-r--r--  1 158,018  Mar  8 01:04 dired.el~
  -rw-r--r--  1 158,018  Mar  8 01:05 dired.el
  -rw-r--r--  1 158,018  Mar  8 01:01 dired.el.~1~
  -rw-r--r--  1 158,018  Mar  8 01:02 dired.el.~2~
  -rw-r--r--  1 158,018  Mar  8 01:03 dired.el.~3~

Re: master 71783e9: Add the string-numeric-lessp function

[Paul Eggert]

Juri Linkov wrote:
> Still this is the weirdest sorting order that I've ever seen
> where single backups come before, but numbered backups after:
>
>    -rw-r--r--  1 158,018  Mar  8 01:04 dired.el~
>    -rw-r--r--  1 158,018  Mar  8 01:05 dired.el
>    -rw-r--r--  1 158,018  Mar  8 01:01 dired.el.~1~
>    -rw-r--r--  1 158,018  Mar  8 01:02 dired.el.~2~
>    -rw-r--r--  1 158,018  Mar  8 01:03 dired.el.~3~

I like it, as it clearly separates the two backup styles in the hopefully rare 
case where people have edited the same file with different backup styles.  (I 
don't use numbered backups so I don't run into the latter sort of names much.)

As it happens, someone complained about this GNU ls behavior many years ago:

https://lists.gnu.org/archive/html/bug-coreutils/2009-02/msg00250.html

with a response essentially the same as mine (great minds think alike ...):

https://lists.gnu.org/archive/html/bug-coreutils/2009-02/msg00254.html

Presumably the behavior could be changed in GNU 'ls', though this sounds low 
priority.  Anyway, I'd rather have Emacs and 'ls' behave the same by default, 
when sorting by version; that seems like a no-brainer.

Re: master 71783e9: Add the string-numeric-lessp function

[Andreas Schwab]

Paul Eggert <eggert@cs.ucla.edu> writes:

> Juri Linkov wrote:
>> Still this is the weirdest sorting order that I've ever seen
>> where single backups come before, but numbered backups after:
>>
>>    -rw-r--r--  1 158,018  Mar  8 01:04 dired.el~
>>    -rw-r--r--  1 158,018  Mar  8 01:05 dired.el
>>    -rw-r--r--  1 158,018  Mar  8 01:01 dired.el.~1~
>>    -rw-r--r--  1 158,018  Mar  8 01:02 dired.el.~2~
>>    -rw-r--r--  1 158,018  Mar  8 01:03 dired.el.~3~
>
> I like it, as it clearly separates the two backup styles in the hopefully
> rare case where people have edited the same file with different backup
> styles.  (I don't use numbered backups so I don't run into the latter sort
> of names much.)

How does that fit with your previous statement?

> That's a good thing, as it's natural for the older version to come before
> the newer one.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: master 71783e9: Add the string-numeric-lessp function

[Paul Eggert]

Andreas Schwab wrote:
> Paul Eggert<eggert@cs.ucla.edu>  writes:
>
>> >Juri Linkov wrote:
>>> >>Still this is the weirdest sorting order that I've ever seen
>>> >>where single backups come before, but numbered backups after:
>>> >>
>>> >>    -rw-r--r--  1 158,018  Mar  8 01:04 dired.el~
>>> >>    -rw-r--r--  1 158,018  Mar  8 01:05 dired.el
>>> >>    -rw-r--r--  1 158,018  Mar  8 01:01 dired.el.~1~
>>> >>    -rw-r--r--  1 158,018  Mar  8 01:02 dired.el.~2~
>>> >>    -rw-r--r--  1 158,018  Mar  8 01:03 dired.el.~3~
>> >
>> >I like it, as it clearly separates the two backup styles in the hopefully
>> >rare case where people have edited the same file with different backup
>> >styles.  (I don't use numbered backups so I don't run into the latter sort
>> >of names much.)
> How does that fit with your previous statement?

It does and it doesn't. My previous statement was about the backup files I 
normally experience, which are like 'dired.el~'; I prefer seeing these files 
before the main file. I don't run into files like 'dired.el.~1~' often, as I 
prefer not to use that style. If I did run into them often, my first reaction 
was I like them segregated (as in the above) even at the cost of putting them 
out of "order". But now that you mention it, I suppose I should have gained more 
experience with this situation before expressing a preference. As the situation 
is unusual (at least for me), it's not likely I will gain experience with it any 
time soon. Anyway, most likely the situation is rare in general and is not worth 
worrying about.

RE: master 71783e9: Add the string-numeric-lessp function

[Drew Adams]

`string-numeric-lessp' really should follow the Emacs
convention and be called `string-numeric-less-p'.

It's not because `string-less-p' is misnamed that we
should add to this mistake.  `time-less-p' is correctly
named, for example.

Or else the rule should be clarified to incorporate
`-lessp' exceptions, so they are within, and not outside,
the rule.


The following 25 are the only such misnamed predicates
I see (in a pretty minimal setup - there may be some
more in Gnus, Org, etc.).  6 of them end in `-lessp'.

 auth-source-specmatchp
 bool-vector-subsetp
 byte-compile-nilconstp
 byte-compile-trueconstp
 byte-optimize-all-constp
 byte-optimize-zerop
 cl--compiler-macro-typep
 cl--macroexp-fboundp
 coding-system-lessp
 custom-facep
 customize-version-lessp
 default-boundp
 dired-tree-lessp
 eieio--typep
 file-attributes-lessp
 gnus-boundp
 gnutls-error-fatalp
 gnutls-errorp
 hack-one-local-variable-constantp
 hack-one-local-variable-eval-safep
 hack-one-local-variable-quotep
 ls-lisp-string-lessp
 slot-boundp
 string-lessp
 uniquify-item-greaterp

That's 25 out of 438 predicates total whose names end in
`p', which I count at the outset in a pretty minimal setup.

So less than 6% of predicate names that end in `p' do not
follow the rule.  94% follow it correctly.

The following predicates are also wrongly named, but they
should not have prefix `cl-' anyway.  Remove the misguided
prefix and these names will all follow the rule.

 cl-endp
 cl-equalp
 cl-evenp
 cl-minusp
 cl-oddp
 cl-plusp
 cl-subsetp
 cl-tailp
 cl-typep

Re: master 71783e9: Add the string-numeric-lessp function

[Johan Bockgård]

Drew Adams <drew.adams@oracle.com> writes:

> `string-numeric-lessp' really should follow the Emacs
> convention and be called `string-numeric-less-p'.
>
> It's not because `string-less-p' is misnamed that we
> should add to this mistake.  `time-less-p' is correctly
> named, for example.
>
> Or else the rule should be clarified to incorporate
> `-lessp' exceptions, so they are within, and not outside,
> the rule.

I think the rule in the Emacs Lisp manual is too simplistic. In practice
we seem to follow something closer to this rule:


   By convention, the names of predicates usually end in the letter p
   (which stands for ``predicate''). Common Lisp uses a uniform
   convention in hyphenating names of predicates. If the name of the
   predicate is formed by adding a p to an existing name, such as the
   name of a data type, a hyphen is placed before the final p if and
   only if there is a hyphen in the existing name. For example, number
   begets numberp but standard-char begets standard-char-p. On the other
   hand, if the name of a predicate is formed by adding a prefixing
   qualifier to the front of an existing predicate name, the two names
   are joined with a hyphen and the presence or absence of a hyphen
   before the final p is not changed. For example, the predicate
   string-lessp has no hyphen before the p because it is the string
   version of lessp (a MacLisp function that has been renamed < in
   Common Lisp). The name string-less-p would incorrectly imply that it
   is a predicate that tests for a kind of object called a string-less,
   and the name stringlessp would connote a predicate that tests whether
   something has no strings (is ``stringless'')!

from CLTL, https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node69.html

RE: master 71783e9: Add the string-numeric-lessp function

[Drew Adams]

> > Or else the rule should be clarified to incorporate
> > `-lessp' exceptions, so they are within, and not outside,
> > the rule.
> 
> I think the rule in the Emacs Lisp manual is too simplistic. In
> practice
> we seem to follow something closer to this rule:
> 
> 
>    By convention, the names of predicates usually end in the letter
>    p (which stands for ``predicate''). Common Lisp uses a uniform
>    convention in hyphenating names of predicates. If the name of the
>    predicate is formed by adding a p to an existing name, such as
>    the name of a data type, a hyphen is placed before the final p if
>    and only if there is a hyphen in the existing name. For example,
>    number begets numberp but standard-char begets standard-char-p.
>    On the other hand, if the name of a predicate is formed by adding
>    a prefixing qualifier to the front of an existing predicate name,
>    the two names are joined with a hyphen and the presence or absence
>    of a hyphen before the final p is not changed. For example, the 
>    predicate string-lessp has no hyphen before the p because it is
>    the string version of lessp (a MacLisp function that has been
>    renamed < in Common Lisp). The name string-less-p would
>    incorrectly imply that it is a predicate that tests for a kind of
>    object called a string-less, and the name stringlessp would
>    connote a predicate that tests whether something has no strings
>    (is ``stringless'')!
> 
> from CLTL,
> https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node69.html

FWIW, that sounds reasonable to me.  It would be harder for the
casual developer to pay attention to (need to distinguish the
two cases, recognizing whether it is about prefixing an existing
predicate).  But given enough experienced eyes to catch an
oversight, it's a good idea, IMO.

If we go that route, let's make this change explicit, and not
just leave the old "simplistic" rule in place in the doc.