Cleanup Issue SUBSEQ-OUT-OF-BOUNDS

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

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.)

Also, the language on page 246 does not make clear whether the prohibition against "start > end" applies to defaulted values as well as explicit values, and does not specify clearly whether the default value for the end argument is the allocated length or the active length.

Proposal (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 active length of the sequence in question (as returned by LENGTH).

Specify that the start value, after defaulting, must not be greater than the end value, after defaulting.

Specify that the default value for the end argument is the active length of the sequence in question.

This may be summarized as follows:

Let X be the sequence within which indices are to be considered. Let S be the :START argument of any standard function, or the second argument to SUBSEQ, whether explicitly specified or defaulted, through omission, to zero. Let E be the :END argument of any standard function, or the third argument to SUBSEQ, whether explicitly specified or defaulted, through omission or an explicitly passed NIL value, to the active length of X, as returned by LENGTH. It is an error if the condition (<= 0 S E (LENGTH X)) is not true.

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 now officially unportable.

Cost of Non-Adoption

Confusion.

Benefits

Removal of a small but important ambiguity in the spec.

Aesthetics

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.

Edit History