Andras Simon <asimon@...> writes:
> While playing with threads with SBCL 0.9.18.18 (in slime) I ran into
> the following:
Thanks for the report. Just to let you know that I at least can reproduce this.
No idea what is causing this yet.
> The reason why I thought this should work is that section 11.2 of the
> manual says "bindings (e.g. using LET) are local to the thread". What
> am I missing?
Nothing. It's a bug. (Well, you could be getting hit by streams not being
threadsafe, but that is not the case here: the same behaviour can be observed
if all three results are saved to different places.)
Cheers,
-- Nikodemus Schemer: "Buddha is small, clean, and serious."
Lispnik: "Buddha is big, has hairy armpits, and laughs."

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."

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

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.

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. This is probably a
bug in SBCL itself. (Alternatively, SBCL might have been corrupted by bad
user code, e.g. by an undefined Lisp operation like (FMAKUNBOUND
'COMPILE), or by stray pointers from alien code or from unsafe Lisp code;
or there might be a bug in the OS or hardware that SBCL is running on.) If
it seems to be a bug in SBCL itself, the maintainers would like to know
about it. Bug reports are welcome on the SBCL mailing lists, which you can
find at <http://sbcl.sourceforge.net/&gt;.
The result is the same with &environment, although any other symbol
beginning with & works.
Luk=E1cs