This page is part of the web mail archives of SRFI 1 from before July 7th, 2015. The new archives for SRFI 1 contain all messages, not just those from before July 7th, 2015.
* Naming: iota John Stone <jstone@xxxxxxxxxxx> writes: > > I understand the rationale for bounds-based numeric sequences >better now, but after some introspection I've realized that since I >always think of APL's iota operator as count-based, I'm having trouble >seeing :IOTA and IOTA: as direct extensions of it. > > So I'd suggest keeping the Evans-style IOTA and thinking up >different names for :IOTA and IOTA:. Though R5RS-conformant, these aren't >ideal names anyway, since they use a character that's likely to be treated >as special either by module systems or by systems that introduce >Common-Lisp-style keywords. For :IOTA, I'd use the name SEQUENCE. I don't >feel as much need for a short name for the much less frequently wanted >IOTA: procedure -- SKIP-SEQUENCE, perhaps, or maybe EQUENCE, would carry the >right connotation of stumbling slightly at the beginning, on discovering >the absence of the expected initial value. I agree that :IOTA and IOTA: names are far from ideal; SEQUENCE is also not a good choice because of its historical associations with BEGIN and common usage in CL community. There is a 4th option not mentioned in the Olin's list: remove all IOTAs from the SRFI. I think they just don't worth the controversy... * TAKE & DROP John Stone <jstone@xxxxxxxxxxx> writes: > As I see it, the functionality question is whether there is any >analogy between the structure of the integers -- negative, zero, and >positive -- and the structure of the operations that, say, DROP performs on >its argument when given a negative, zero, or positive value. If there is >no such analogy, having DROP accept negative arguments is just a kludge, >and we should get rid of it regardless of the consequences to the >namespace. Couldn't agree more. > But I think that there is such an analogy. Here's the vision I >have: DROP sets up a cutting board, with the list spread out from left to >right in the middle of the board, and a pair of blades, hovering above the >board, separated horizontally by the number of elements in the list. The >numerical argument now positions the blades: If it is zero, the blades are >positioned at the beginning and end of the list; if it is negative, both >blades are shifted leftwards; if it is positive, they are shifted >rightwards. Finally the blades fall, and the return value is the segment >of the list that lies between them; the rest is lopped off. TAKE is >similar, except that we return the lopped-off part. This is an interesting analogy indeed. The problem as I see it is that this analogy is way too complex for a supposedly primitive procedures like TAKE and DROP. It is possible to give an analogy for a lot of things given a cutting board and two blades -- imagine what can be done if you add a fork! :) As for the namespace pollution, I think we can consider these options too: a) sacrifice variants that operate on lists 'from end' -- lists are sequential structures and operations that work 'upstream' are significantly slower and are probably less useful in practice. b) leave out STRING-TAKE, VECTOR-DROP etc. Strings and vectors have constant-time access and SUBLIST/SUBVECTOR are adequate in most cases * Add SUBLIST? I agree with Olin's analysis in general, but I think that SUBLIST *is* an acceptable replacement for variants of TAKE / DROP working 'from end' (and it has the same performance characteristics). To be compatible with SUBSTRING, I would leave out all fancy indexing features from SUBLIST's specification; making the END argument optional is also an overkill - one may just use DROP or LIST-TAIL. SUBLIST! can also be useful. Sergei