[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]


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.


[Starting Points][Contents][Index][Symbols][Glossary][Issues]
Copyright 1996-2005, LispWorks Ltd. All rights reserved.