[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Issue SUBSEQ-OUT-OF-BOUNDS



Issue:         SUBSEQ-OUT-OF-BOUNDS

References:    :START and :END arguments (246-247), SUBSEQ (248)

Category:      CLARIFICATION

Edit history:  24-Mar-88, Version 1 by Steele

Problem description:

The descriptions of :START and :END arguments, and of SUBSEQ, do not
explicitly address the question of out-of-bounds indices.  (The language on
page 246, "These arguments should be integer indices into the sequence," is
considered too vague on this point.)


Proposal (SUBSEQ-OUT-OF-BOUNDS:IS-AN-ERROR):

Specify that it is an error for the :START argument of any standard
function, or the second argument to SUBSEQ, to be less than zero.  Specify
that it is an error for the :END argument of any standard function, or the
third argument to SUBSEQ, to be greater than the length of the sequence in
question (as returned by LENGTH).

(Note that there is already a requirement that a start argument not
be greater than an end argument.)

Test Cases/Examples:

(SUBSEQ "Where's the beef?" -1 5) might be assumed to be "Where" or " Where".

(SUBSEQ "Where's the beef?" -3 -3) might be assumed to be "".

(SUBSEQ "Where's the beef?" 16 18) might be assumed to be "?" or "? ".

(SUBSEQ "Where's the beef?" 10000 10000) might be assumed to be "".

Under this proposal each of these situations is an error, and portable
programs may not rely on their behavior.

Rationale:

We don't want code indexing off the ends of arrays.

Current practice:

KCL interpreted and compiled code signals an error.

Symbolics Common Lisp interpreted and compiled code signals an error; the
compiler also issued an out-of-range warning (possible because the
arguments were all constant).

Lucid Common Lisp interpreted and compiled code signals an error.


Cost to Implementors:

None.

Cost to Users:

Users who depended on some specific implementation behavior in these cases
may find that their pragmatically unportable code is not officially
unportable.

Cost of non-adoption:

Confusion.

Benefits:

Removal of a small but important ambiguity in the spec.

Esthetics:

It seems cleaner not to allow indexing off the end of an array, and
by extension not allow it for any sequence.

Discussion:

This merely clarifies the original intent of the passage on page 246.