GNU bug report logs - #17485
(srfi srfi-1) reduce-right does not scale, version 2.0.9

Previous Next

Full log

View this message in rfc822 format

From: David Kastrup <dak <at> gnu.org>
To: Mark H Weaver <mhw <at> netris.org>
Cc: 17485 <at> debbugs.gnu.org
Subject: bug#17485: [PATCH 1/3] Let length+ return the length of dotted lists rather than #f
Date: Thu, 05 Jun 2014 15:57:30 +0200

David Kastrup <dak <at> gnu.org> writes:

> David Kastrup <dak <at> gnu.org> writes:
>
>>> Otherwise, this function looks good to me, but I'd prefer to give it a
>>> new name and move it into list.c, rather than extending SRFI-1's
>>> 'length+'.
>
> It's not an "extension" of SRFI-1's length+: it just does the same as
> the SRFI-1 reference implementation.  It is just a different choice of
> working with unspecified behavior than yours.
>
>>> Hmm, coming up with names is hard.  Maybe 'length*'?
>>
>> Given what cons* (and use of id* in syntax rules) does, the name seems
>> inappropriate.  length* would be a good name for
>>
>> (length* clist1 clist* ... )
>>
>> returns the length of the shortest finite list in the given lists, #f
>> if there is none.  Which would be actually a rather nice building
>> block to have for several srfi-1 functions and would basically not
>> make us need length+ at all in its implementation.
>
> And that's actually the core of the argument: do we really want to offer
> a "length+" that is at best marginally useful for srfi-1 itself?
>
> For a library design, that sounds a lot like "does not eat its own dog
> food".  Are we really doing users a favor by filling in the
> "unspecified" corners of the srfi-1 in a manner not making for a
> coherent whole?

Here is another: if I make length* do the "length of shortest list"
thing, it would be silly _not_ to use it in the multiple-list for-each,
fold, map etc.  So we again get in the situation that the respective
functions would get "lax" in the multi-argument case since length*, if
it were to be used in take-right, _has_ to be lax in the single-argument
case, rendering its behavior again unacceptable for for-each/map/etc and
thus rather pointless as a length* operator.

I am not particularly interested in investing work into further patches
each constituting several days of work getting thrown in the trash, so
I won't even bother making further proposals that can but fail to meet a
set of mutually contradictory design criteria.

-- 
David Kastrup

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.