#

## Issue SUBSEQ-OUT-OF-BOUNDS Writeup

    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
    	       29-Mar-88, Version 2 by Steele, in response to Moon's comments

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

    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.

Copyright 1996-2001, Xanalys Inc. All rights reserved.