[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
SRFI-1 round 2 discussion
* 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
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/ =========