Re: [Chicken-users] Bug in SRFI-13 lib?

[Jim Ursetto]

On 2/16/08, Kon Lovett <address@hidden> wrote:
> On Feb 16, 2008, at 6:55 PM, Matt Gushee wrote:
>
> > Nonetheless, I've gotten accustomed to a world where datatypes are
> > used very precisely to model the semantics of your problem domain.
> > So when I see a function behaving in a way that implies semantics
> > that aren't in the spec, it just doesn't feel right. Even if I know
> > it's not really a problem in practice.
>
> Yeah, it isn't right.
>
> Some of the SRFI documents are not up-to-date with respect to the
> reference implementation. This isn't true in general & the more
> recent are probably in-sync.

This issue happened to be pointed out on the post-finalization
discussion archive for SRFI-13 a couple years ago, along with
a little fix.

http://srfi.schemers.org/srfi-13/post-mail-archive/msg00006.html

If you take a look at the pre-finalization discussions of SRFI-13,
you'll find that the string<, string=, etc. procedures were
originally intended to return a "mismatch index" along the lines
of that described in string-compare.  However, it was pointed out
that if this behavior was required, it would preclude string= and
string<> from simply short-circuiting based on comparison of the
string lengths.  So the mismatch index was changed to a boolean
return value in the SRFI, with <, > etc. also changed to boolean
for consistency.

However, it seems Olin didn't modify the reference implementation
to strictly obey this change--perhaps he found it useful or
it just slipped by.  It does do the quick length test, though.
So the mismatch index shines through, but you rely on it at
your own peril.

This is all made a little more confusing by the lack of a
final question mark on the end of these predicates--which
sometimes indicates a "boolean-plus" value is intentionally being
returned; in other words, either #f or a useful true value.
Such is the case with memq, memv, etc.  But the dropping of the ?
was, as far as I can tell, done for aesthetic reasons only.
Combine that with the historical baggage of the mismatch index
and the behavior of the reference implementation, and you have
a recipe for discombobulation.

I hope this explanation made you feel a little better. ;)