SLOT-VALUE bug?

[LWW 5.0.1]

If I compile and load the code at the end of this email, I get this:

  CL-USER 1 > (quux (make-instance 'a))
  BAR

My gut feeling tells me that this is a bug in SLOT-VALUE and I'm
seeing some kind of optimization which doesn't work.  But maybe I'm
wrong and what I'm doing is against the (ANSI) law.  Any thoughts?

FWIW, AllegroCL, CMUCL, SBCL, and CLISP all return 'FOO which is what
I expected.

Cheers,
Edi.



  (in-package :cl-user)

  (defclass a ()
    ((foo :initform 'foo)))

  (defclass mixin ()
    ((bar :initform 'bar)))

  (defclass b (a mixin)
    ())

  (defmethod quux ((thing a))
    (change-class thing 'b)
    (slot-value thing 'foo))

Fwd: SLOT-VALUE bug?

My bad. I should have read more closely.
Yes, I now get 'BAR when I just compile an edit buffer with your earlier code and
(pprint (quux (make-instance 'a))).

If it matters for cross reference, here are the optimize settings (default) used when compiling the buffer:
;;; Safety = 3, Speed = 1, Space = 1, Float = 1, Interruptible = 0
;;; Compilation speed = 1, Debug = 2, Fixnum safety = 3

Cheers,
Chris

On 12/26/06, Edi Weitz <edi@agharta.de> wrote:

On Mon, 25 Dec 2006 20:33:57 +0200, "Christopher Brown" < cjbrown102@gmail.com> wrote:

> Not sure what's up, but I just tried this on LW pro, 5.0.1, Mac,
> Intel and get 'FOO

Yes, I get the same in LWW if I do it in the REPL.  That's why I said
you should compile and load the code (from a file).  Do you still get
'FOO in this case?  (I don't expect interpreted slot access to be
optimized.)

Cheers,
Edi.

Re: SLOT-VALUE bug?

Hello Edi,

| [LWW 5.0.1]
|
| If I compile and load the code at the end of this email, I get this:
|
|   CL-USER 1 > (quux (make-instance 'a))
|   BAR
|
| My gut feeling tells me that this is a bug in SLOT-VALUE and I'm
| seeing some kind of optimization which doesn't work.  But maybe I'm
| wrong and what I'm doing is against the (ANSI) law.  Any thoughts?

Misfunctions the same on LWW 4.4.6. Setting :optimize-slot-access to NIL
does help, i.e.

(defclass a ()
  ((foo :initform 'foo))
  (:optimize-slot-access nil))

BTW, defining a reader and getting a slot value via it works in any case,
e.g.

(defclass a ()
  ((foo :initform 'foo :reader foo)))
....
(defmethod quux ((thing a))
  (change-class thing 'b)
  (list (slot-value thing 'foo) (foo thing)))

> (quux (make-instance 'a)) => (BAR FOO)
--
Sincerely,
Dmitriy Ivanov

Re: SLOT-VALUE bug?

On 25 Dec 2006, at 18:31, Edi Weitz wrote:

>
> [LWW 5.0.1]
>
> If I compile and load the code at the end of this email, I get this:
>
>   CL-USER 1 > (quux (make-instance 'a))
>   BAR
>
> My gut feeling tells me that this is a bug in SLOT-VALUE and I'm
> seeing some kind of optimization which doesn't work.  But maybe I'm
> wrong and what I'm doing is against the (ANSI) law.  Any thoughts?

Yes, you committing crimes against the laws of ANSI. ;)

See the notes section about change-class: "The generic function  
change-class has several semantic difficulties. First, it performs a  
destructive operation that can be invoked within a method on an  
instance that was used to select that method. When multiple methods  
are involved because methods are being combined, the methods  
currently executing or about to be executed may no longer be  
applicable. Second, some implementations might use compiler  
optimizations of slot access, and when the class of an instance is  
changed the assumptions the compiler made might be violated. This  
implies that a programmer must not use change-class inside a method  
if any methods for that generic function access any slots, or the  
results are undefined."

Some think that this wording is still too optimistic... :}

Pascal

-- 
Pascal Costanza, mailto:pc@p-cos.net, http://p-cos.net
Vrije Universiteit Brussel, Programming Technology Lab
Pleinlaan 2, B-1050 Brussel, Belgium

Re: SLOT-VALUE bug?

Pascal Costanza <pc@p-cos.net> writes:

> This implies that a programmer must not use change-class inside a
> method if any methods for that generic function access any slots, or
> the results are undefined.

Wow! Thanks for pointing out that. I think I have to grep through my
source files for change-class...

(And Edi's example indeed returns FOO if the method is replaced by an
 ordinary function)
-- 
  (espen)

Re: SLOT-VALUE bug?

On Tue, 26 Dec 2006 22:39:18 +0100, Pascal Costanza <pc@p-cos.net> wrote:

> Yes, you committing crimes against the laws of ANSI. ;)

Ah, bummer!  Thanks for the explanation.

> Some think that this wording is still too optimistic... :}

And I thought Common Lisp was a flexible language... :)

Thanks,
Edi.