Steel Bank Common Lisp

Berki Lukacs Tamas writes:
>=20
> The following form:
>=20
> (defun foo (&whole whole) 42)
>=20
> Yields this answer on SBCL 0.9.14 and 1.0 (on Ubuntu 6.10 without SLIME=
,
> simple using the CLI):
>=20
> debugger invoked on a SB-INT:BUG in thread #<THREAD "initial thread"
> {A8154E9}>:
>=20
>     unknown LAMBDA-LIST-KEYWORD in lambda list: &WHOLE.=20

As expected.  Why would you want to use a MACRO lambda list with deFUN?

> This is probably a bug in SBCL itself.=20

No, this is mandated by the CL specifications.

DEFUN uses ordinary lambda lists, not macro lambda lists.
http://www.lispworks.com/documentation/HyperSpec/Body/03_da.htm


=20
> The result is the same with &environment, although any other symbol
> beginning with & works.

The other symbols beginning with & are normal symbols.  (That is, all
the symbols that are not in LAMBDA-LIST-KEYWORDS).
&FOO isn't even in the CL package!



--=20
__Pascal Bourguignon__                     http://www.informatimago.com/

ATTENTION: Despite any other listing of product contents found
herein, the consumer is advised that, in actuality, this product
consists of 99.9999999999% empty space.

On Nov 30, 2006, at 8:35 PM, Pascal Bourguignon wrote:

> Berki Lukacs Tamas 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  
>> SLIME,
>> simple using the CLI):
>>
>> debugger invoked on a SB-INT:BUG in thread #<THREAD "initial thread"
>> {A8154E9}>:
>>
>>     unknown LAMBDA-LIST-KEYWORD in lambda list: &WHOLE.
>
> As expected.  Why would you want to use a MACRO lambda list with  
> deFUN?
>
>> 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.

> DEFUN uses ordinary lambda lists, not macro lambda lists.
> http://www.lispworks.com/documentation/HyperSpec/Body/03_da.htm
>
>
>> The result is the same with &environment, although any other symbol
>> beginning with & works.
>
> The other symbols beginning with & are normal symbols.  (That is, all
> the symbols that are not in LAMBDA-LIST-KEYWORDS).
> &FOO isn't even in the CL package!

Looking at the code for parse-lambda-list-like-thing, I can't see why  
this shouldn't throw a compiler error instead of calling #'bug.

Cyrus

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  
>>> SLIME,
>>> simple using the CLI):
>>>
>>> debugger invoked on a SB-INT:BUG in thread #<THREAD "initial thread"
>>> {A8154E9}>:
>>>
>>>     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
violations, etc.

>> As expected.  Why would you want to use a MACRO lambda list with  
>> deFUN?
>>
>>> 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.

Cheers,

  -- Nikodemus              Schemer: "Buddha is small, clean, and serious."
                   Lispnik: "Buddha is big, has hairy armpits, and laughs."