[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