[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Drew Adams
Subject: RE: master 71783e9: Add the string-numeric-lessp function
Date: Mon, 7 Mar 2016 14:03:53 -0800 (PST)

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]