[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Date: 18 Jun 86 17:57 EDT
Watch me ride on both sides of the fence here.
I think (SUBSEQ s x y) should only return an error if x<0 or y<0. I see no
reason to force an expression like (SUBSEQ #(a b c) 0 9) to return an error
when it could return a perfectly useful value instead.
There are lots of cases for lots of functions where one could dream up
a "perfectly useful value" to return in a currently erroneous situation.
For example, inasmuch as (CAR 'NIL) = (CDR 'NIL) = NIL, maybe we should
define (CAR 9) = (CDR 9) = 9. (Or perhaps (CAR 9) = 1 and (CDR 9) = 4.)
If we were to define (SUBSEQ #(a b c) 1 9) to be #(b c), then I don't see
why we should restrict the indices to be non-negative: why not
(SUBSEQ #(a b c) -9 2) = #(a b) as well?
Here are two more arguments against returning an error. First, whether or
not SUBSEQ returns an error, it still has to check the length of the sequence
in order to do the right thing. So if we force the user to write
(SUBSEQ x 0 (min 5 (length x))) the length gets checked twice: once by the
user code, and once by SUBSEQ. This seems wasteful.
Well, SUBSEQ must check the length if it is defined to SIGNAL an error for
an out-of-bound index. If we only require that an out-of-bound index IS an
error, then no check is required in principle (although an implementation
may make such a check in practice).
The second argument is that for lists, there is already precedent for
permitting out of range indexing, e.g. (NTH '(a b c) 7) returns NIL rather
than an error. I don't object to ELT returning an error in this case because
there's no more natural thing to do in the case of vectors. (Consing up an
returning a new empty vector would be a dumb idea.) But in the case of
SUBSEQ there is a perfectly good behavior, namely, return as much of the
sequence as actually exists.
The behavior of NTH is a "natural" consequence of (CAR NIL) = (CDR NIL) = NIL.
The index for NTH must be non-negative, says the spec.