Re: `compare-strings' style question

[tomas@tuxteam.de]

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