SRFI-1 round 2 discussion

[John Stone <jstone@xxxxxxxxxxx>]

* Naming: iota

        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.

* TAKE & DROP

        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.

        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.

* lists-as-sets funs put in separate module?

 > In my view, lists-as-sets aren't a different data type, they are a particular
 > use of lists. These functions are sufficiently useful to warrant being
 > included in the general list lib.

        Well, it's your call, but in my opinion the crucial question is not
``How often will users need lists-as-sets?'' but ``How often will users
want lists without needing lists-as-sets?''  It's a lot easier to load two
libraries when you want both of them than to load half a library when you
want only part of it, so I think that designers should start with a bias
towards splitting and against lumping.

* Argument order of = equivalence predicates

        Terminological point: It isn't an equivalence predicate unless it
is reflexive, _symmetric_, and transitive.  Notational point:  It's
extremely misleading to use the identifier `=' for a predicate that is not
an equivalence predicate.

======  John David Stone - Lecturer in Computer Science and Philosophy  =====
==============  Manager of the Mathematics Local-Area Network  ==============
==============  Grinnell College - Grinnell, Iowa 50112 - USA  ==============
==========  stone@xxxxxxxxxxxxx - http://www.math.grin.edu/~stone/  =========