First of all, I'd like to say thanks to the people who mailed me and
posted replies to my recent problem of not knowing about
symbol-macrolet.
This leads me to hope that there is someone who can help me with the
following problem:
I am trying to do a defsetf for a function that allows &key arguments,
but they don't seem to work. This is an example of the kind of thing
I am doing:
(defun test1 (q &key (r nil))
`(,q ,r))
(defsetf test1 (q &key (r nil)) (s)
`(list ,q ,r ,s))
If I try some tests on these, I get:
>(test1 3 :r 5)
(3 5)
>(test1 3)
(3 NIL)
>(setf (test1 3) 7)
(3 NIL 7)
>(setf (test1 3 :r 5) 7)
Error: #:G1054 is not a keyword.
What am I missing? If I use &optional instead of &key, everything
works fine. In CLTL2, page 138, it says that "&optional, &rest and
&key" are permitted in the lambda list, so why doesn't it work?
I have tried it on CMU-CL (dated 25-9-91, Python v1.0), and AKCL
(v1.605 and v1.608), so I can't see that it is a bug in a particular
implementation.
Thanks for your time,
Gordon.
--------------------------------------------------------------------
······@robots.oxford.ac.uk | If God had meant man to fly, He |
Gordon Buxton | wouldn't have given us the railways |
--------------------------------------------------------------------
In article <····@inca.comlab.ox.ac.uk> ······@robots.oxford.ac.uk (Gordon Buxton) writes:
>>(setf (test1 3 :r 5) 7)
>
>Error: #:G1054 is not a keyword.
I think it's a bug. It looks like it's doing something equivalent to
transforming the SETF form into
(let* ((#:G1 3) (#:G2 :R) (#:G3 5) (#:G4 7))
(setf (test1 #:G1 #:G2 #:G3) #:G4))
But then when the keyword processing runs (at macroexpansion time), it
can't find the :R in the argument list. The transformation is probably
done to preserve order of evaluation.
>I have tried it on CMU-CL (dated 25-9-91, Python v1.0), and AKCL
>(v1.605 and v1.608), so I can't see that it is a bug in a particular
>implementation.
It also fails in CMUCL 16d and Lucid 4.0 and 4.1-beta.
However, it works in Symbolics Genera 8.1.1. I think that's because it
runs a code walker over the form and sees that nothing is dependent on
order of evaluation, so it leaves it as it is. I suspect it could fail for
more complex forms.
--
Barry Margolin
System Manager, Thinking Machines Corp.
······@think.com {uunet,harvard}!think!barmar