Bug in Xerox-Medley Dec PCL

[Arun Welch <welch@cis.ohio-state.edu>]

We've noticed the following behaviour in the Xerox-Medley version of
the latest (no cute name) pcl.

3/1> (defclass poodle nil ((ears :type number) (tail :type symbol)))
3/2> (setf fifi (*make-instance 'poodle))
3/3> (slot-boundp fifi 'ears) returns NIL
3/4> (slot-value fifi 'ears) prints "The slot EARS is unbound in the
	object #<POODLE 12345566>" (it does *not* give an error/break)
3/5> (setf (slot-value fifi 'ears) 4) prints "The slot EARS is unbound in the
	object #<POODLE 1234566>" (it does *not* give an error/break)

Shouldn't clause 3/4 signal an error instead of returning? And,
shouldn't 3/5 return 4? The cause of all this turns out to be:

>...But I have no idea of a workaround. Here's what happens: you do a
>(setf (slot-value foo 'tentacles) 'slimy). The xerox says: hah, I know what
>she's up to -- she wants to do a value-setting thing. But then she
>might change her mind later, so instead of just doing the appropriate
>setf-method, first I'll call undoably-save, which will squirrel away
>for her protection both the thing whose value she's changing *and the
>original pre-set value*. So, I'll take the setf form around the
>form and just do a l'il old slot-value to get the original value that
>she's about to change...
>Voila. Undoably-save (or undoably-store or whatever its called) magically
>goes ahead and does a slot-value on an unbound slot...


Has anyone else noticed this, and have a patch? 

...arun