bug-guile
[Top][All Lists]
Advanced

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

bug#17485: [PATCH 1/3] Let length+ return the length of dotted lists rat


From: David Kastrup
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
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)

David Kastrup <address@hidden> writes:

> David Kastrup <address@hidden> 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





reply via email to

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