out-of-range subsequences

[Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>]

    Date: 18 Jun 86 17:57 EDT
    From: Dave.Touretzky@A.CS.CMU.EDU

    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.

To take a simple function and then make its definition inconsistent with
the spirit of the language, just to squeeze in an extra feature, is the
way to make the language inconsistent and hard to learn.

    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.

To take a simple function and then make its definition inconsistent with
the spirit of the language, just to save a few microseconds, is another
way to make the language inconsistent and hard to learn.

    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.

But there is no such precedent for arrays, nor for sequences in general.
NTH, unfortunately, needs to behave that way for consistency, on the
grounds that one would expect that NTH could be defined the obvious way
using CAR and CDR, and CAR and CDR both return NIL when given NIL.

(Indeed, the whole business of CAR of NIL was one of those features
shoehorned into the language for a little extra convenience, at the cost
of consistency.  As we used to say at MIT about TECO macros: "A moment
of convenience; a lifetime of regret.")