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.