CLHS: Issue ARGUMENT-MISMATCH-ERROR-MOON Writeup

#

## Issue ARGUMENT-MISMATCH-ERROR-MOON Writeup

    Issue:        ARGUMENT-MISMATCH-ERROR-MOON
    Reference:    dpANS 12.24
                    3.5 Error Checking in Function Calls
                    3.5.1.1 Safe and Unsafe Calls
                    3.5.1.2 Too Few Arguments
                    3.5.1.3 Too Many Arguments
                    3.5.1.4 Unrecognized Keyword Arguments
                    3.5.1.5 Invalid Keyword Arguments
                    3.5.1.6 Odd Number of Keyword Arguments
                    3.5.1.7 Destructuring Mismatch
                  X3J13/92-3212 David Moon comment #12
    Category:     EDITORIAL
    Edit History: Version 1, 12/13/92, Kim Barrett
                  Version 2, 5/23/93, Sandra Loosemore (amendment from minutes)
    Status:       Proposal FIX passed without objection, March 1993

    Problem Description:

     There are several problems in section 3.5 "Error Checking in Function Calls"
     beginning on page 3-51:

     a) The portions of section 3.5.1.1 referring to generic functions and
     call-next-method say "safe" when they should say "safe or system code". The
     generic function, an applicable method, or the method combination might be
     defined in system code.

     b) The word "otherwise" beginning the second paragraph of section 3.5.1.2
     doesn't make sense. It should be replaced by "If too few arguments are
     supplied". Similar corrections are required in sections 3.5.1.3, 3.5.1.4,
     3.5.1.5, and 3.5.1.6, but *not* 3.5.1.7.

     c) The third paragraphs of sections 3.5.1.2, 3.5.1.3, 3.5.1.4, 3.5.1.5,
     3.5.1.6, and 3.5.1.7 are each completely redundant and should be deleted.

     d) The first paragraph of section 3.5.1.7 refers to "Section mm.nn". Relevant
     information does not seem to be in section 3.4.4 or 3.4.5; was this section
     omitted entirely?

    Proposal (ARGUMENT-MISMATCH-ERROR-MOON:FIX):

     a. In the first of the specific cases in 3.5.1.1 (generic function), change
     the second use of the term \term{safe} to be "\term{safe code} or
     \term{system code}".  Similarly in the last of the specific cases
     (call-next-method).

     b. At the beginning of the second paragraph of each of 3.5.1.2 through
     3.5.1.6, change the phrase "Otherwise, in a \term{safe call}" to "If this
     \term{situation} occurs in a \term{safe call}".

     c. Delete the third paragraphs of sections 3.5.1.2 through 3.5.1.7.

     d. Repatriate the missing section reference.

     e. In the first paragraph of each of 3.5.1.2 and 3.5.1.3, add a period
     following the first occurance of "\term{function}".

    Editorial Impact:

     A small number of explicitly specified edits.

    Rationale:

    Examples:

    Current Practice:

    Cost to Implementors:

    Cost to Users:

    Performance Impact:

    Benefits:

    Aesthetics:

    Discussion:

     Proposal item (e) was noted as being needed while preparing the other items.

Copyright 1996-2005, LispWorks Ltd. All rights reserved.