[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: `compare-strings' style question
From: |
tomas |
Subject: |
Re: `compare-strings' style question |
Date: |
Fri, 20 Nov 2009 08:00:39 +0100 |
User-agent: |
Mutt/1.5.15+20070412 (2007-04-11) |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thu, Nov 19, 2009 at 03:54:20PM -0500, Barry Margolin wrote:
> In article <87einuij59.fsf@lola.goethe.zz>, David Kastrup <dak@gnu.org>
> wrote:
[...]
> > In my opinion, t was the wrong choice for a match. nil would have been
> > much better because you can't use the result of compare-strings as a
> > condition.
> >
> > But I suppose there is not much one can do now because of compatibility.
>
> That would still be weird, because
>
> (not (compare-strings ...))
>
> would be the way to tell if they're equivalent. C has the same problem
> with its strcmp() function, which returns negative, 0, or positive,
> where 0 is C's falsehood.
Yes, that would be a similar problem as C, where zero's alter ego is
false. It still looks a bit funny to say
if(!strcmp(foo, bar)) ...
...but at least, it's just a problem of name choice (more appropriate
would have been something along the lines of strdiff).
> The basic problem is that IF is designed to work with binary predicates,
> and this operation is trinary.
>
> Maybe compare-strings should have been defined like strcmp, returning 0
> for the middle case. Then you wouldn't be tempted to think of it as a
> predicate. (zerop (compare-strings ...)) doesn't seem as weird as (not
> (compare-strings ...)).
Yes, I would have preferred this choice (but nil would have been fine
too).
Thanks
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFLBj6XBcgs9XrR2kYRAsz/AJ47RD83WcbAmKNJ3zDVO2RLorOEXwCePi9z
q0SAJuLd7lCI6MHoi2ShLlw=
=D4Be
-----END PGP SIGNATURE-----