* Naming: iota

John Stone <xxxxxx@cs.rice.edu> 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 <xxxxxx@cs.rice.edu> 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