Cyrus Harmon <ch-sbcl@...> writes:
>>> The following form:
>>> (defun foo (&whole whole) 42)
>>> Yields this answer on SBCL 0.9.14 and 1.0 (on Ubuntu 6.10 without
>>> simple using the CLI):
>>> debugger invoked on a SB-INT:BUG in thread #<THREAD "initial thread"
>>> unknown LAMBDA-LIST-KEYWORD in lambda list: &WHOLE.
In any case, signalling a BUG is wrong from the SBCL point of view,
since it is ment to indicate a probably bug in SBCL: invariant
>> As expected. Why would you want to use a MACRO lambda list with
>>> This is probably a bug in SBCL itself.
>> No, this is mandated by the CL specifications.
> The spec mandates that you drop into the debugger? I would imagine
> that the spec mandates that an error be thrown, but I admit I haven't
> looked at the spec.
Looking at the spec, I cannot see any point where lambda-list-keywords
are given any special powers beyond their role in parsing the lambda-lists
they belong to.
My reading is, that (IMO unfortunately):
(defun foo (&whole form) form)
is no different from:
(defun foo (cons form) form)
that is, both &WHOLE and CONS are just ordinary variables there.
If someone can point a finger at a place where the &WHOLE is given
licence to signal an error should it appear in an ordinary
lambda-list, I'd be quite happy.
-- Nikodemus Schemer: "Buddha is small, clean, and serious."
Lispnik: "Buddha is big, has hairy armpits, and laughs."