[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
function-keywords meets &rest
Date: Mon, 8 Jan 90 13:31 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Date: Sun, 7 Jan 90 16:17 PST
From: Gregor.pa@Xerox.COM
We may have already resolved this, but what happens when
fucntion-keywords gets a method where the arglist has &rest. Is the
second returned value T??
(A second returned value of T is documented as meaning the lambda-list
specifies &allow-other-keys).
I couldn't find any evidence of this issue having been raised before.
The lambda-list congruency rules (Aug 29 1989 4:06 draft, p.4-19) don't
treat &rest and &allow-other-keys the same. In rule 3 &rest without
&key is the same as &allow-other-keys, but in rule 4 they are different.
An implementation is not a specification, but in the Symbolics implementation
of FUNCTION-KEYWORDS currently the second value is true if and only if
(member '&allow-other-keys lambda-list) is true (provided that the
lambda-list is syntactically valid).
Unless there is a reason to change it, I would stick with the 88-002R
language, which implies that the values are NIL NIL if the lambda-list
does not contain &KEY, and that the values are not affected by the
presence of &REST.
After being confused about this myself last week, I've found another reason
not to change it. The proposal was that FUNCTION-KEYWORDS of a method
with &REST should do the same thing as FUNCTION-KEYWORDS of a method
with &ALLOW-OTHER-KEYS. The problem is that &REST and &ALLOW-OTHER-KEYS
do not actually mean the same thing in a method arglist.
&ALLOW-OTHER-KEYS in a method arglist means that the generic function
should accept any keywords whatsoever, but does not by itself make those
keyword arguments visible to the method.
&REST in a method arglist has no effect on what keywords are accepted
by the generic function, but makes all the keyword arguments that were
supplied visible to the method.
Thus the two lambda-list-keywords are almost opposite in meaning.