David Kastrup <[email protected]> writes: > David Kastrup <[email protected]> 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
