#

## Issue ARGUMENT-MISMATCH-ERROR-AGAIN Writeup

    Issue:         ARGUMENT-MISMATCH-ERROR-AGAIN
    Forum:         Cleanup
    References:    ARGUMENT-MISMATCH-ERROR, draft 10.156 pp.3-44, 3-48
    Category:      CHANGE
    Edit history:  9-Dec-91, Version 1 by Moon
    Status:        Accepted 10-Dec-91; 10-1

    Problem description:

      ARGUMENT-MISMATCH-ERROR left out two cases of argument mismatch error:
      (1) a mismatch between a destructuring lambda list and the tree being destructured;
      (2) an odd number of arguments supplied to the keyword parameters.

      In the current specification, these are both "the consequences are undefined."
      This is inconsistent with the handling of the other five argument mismatch errors.

    Proposal (ARGUMENT-MISMATCH-ERROR-AGAIN:CONSISTENT):

      Add two new subsections to section 3.5, with wording analogous to the subsections
      already present, to cover these cases, as follows:

      (1) After the existing sentence "The pattern and the \term{macro form} must have
      compatible \term{tree structure}; that is, their \term{tree structure} must be
      equivalent, or it must differ only in that some \term{leaves} of the pattern
      match \term{non-atomic} \term{objects} of the \term{macro form}." add "In a safe
      call, an error of type program-error must be signaled; otherwise, the situation
      has undefined consequences." followed by the boilerplate about the exact point of
      the signal.

      (2) Add the following: "An odd number of arguments must not be supplied for the
      keyword parameters. In a \term{safe} \term{call}, an error \oftype{program-error}
      must be signaled unless either \keyref{allow-other-keys} was used in the
      \term{function}'s definition, or ``\f{:allow-other-keys \term{true}}'' was used
      in the \term{call}; otherwise, the \term{situation} has undefined consequences."
      followed by the boilerplate about the exact point of the signal.

      Move some text now on page 3-44 to the new subsection of 3.5 dealing with destructuring.

    Rationale:

      Consistency.

    Current practice:

      CLtL did not require this level of error checking, so it's entirely
      likely that there are implementations which do not conform.

    Cost to Implementors:

      The cost of adding additional error checking in some implementations.

    Cost to Users:

      More robust code.

    Cost of non-adoption:

      Less safety when users use defmacro; inconsistency in the specification.

    Performance impact:

      None.

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