CLHS: Issue CLOS-ERROR-CHECKING-ORDER Writeup

#

## Issue CLOS-ERROR-CHECKING-ORDER Writeup

    Issue:        CLOS-ERROR-CHECKING-ORDER
    Reference:    dpANS 12.24
                    Section 7.6.5 Keyword Arguments in Generic Functions and Methods
                    Section 7.6.6 Method Selection and Combination
                    no-applicable-method, p.7-47
                  X3J13/92-3248 David Moon comment #48
    Category:     CLARIFICATION/CHANGE
    Edit History: Version 1, 12/13/92, Kim Barrett
    Status:	      Proposal NO-APPLICABLE-METHOD-FIRST passed (10+1)-0 on
                  letter ballot 93-302.

    Problem Description:

     There is no specification of the ordering between the check for
     no-applicable-method and the check for unexpected keyword arguments.
     Specifically, section 7.6.5 states that if a generic function is passed a
     keyword argument that no applicable method accepts, an error should be
     signaled, while section 7.6.6 states that if there are no applicable methods
     then the generic function no-applicable-methods is called.

    Proposal (CLOS-ERROR-CHECKING-ORDER:NO-APPLICABLE-METHOD-FIRST):

     Check for no applicable method first.  Change the end of the last paragraph
     of section 7.6.6 from

        If a \term{generic function} is called and no \term{methods} are
        \term{applicable}, the \term{generic function} \funref{no-applicable-method}
        is invoked.

     to

        If a \term{generic function} is called and no \term{methods} are
        \term{applicable}, the \term{generic function} \funref{no-applicable-method}
        is invoked, with the \term{results} from that call being used as the
        \term{results} of the call to the original \term{generic function}.  Calling
        \funref{no-applicable-method} takes precedence over checking for acceptable
        keyword arguments; \SeeSection{... section name for 7.6.5 ...}.

    Editorial Impact:

     Changing or adding a couple of lines of text.

    Rationale:

     It was clearly intended that the call to no-applicable-methods be for value,
     rather than for effect.  It just wasn't actually specified that way anywhere.

     Adopting the suggested order would remove an ambiguity from the specification
     and would make the no-applicable-method feature a little more useful.

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