[Openmcl-devel] :initarg caching

[Sven Van Caekenberghe]

I have encountered something odd in an image that I have currently open 
in emacs/slime:

CL-USER> (defclass foo () ())
#<STANDARD-CLASS FOO>
CL-USER> (defclass foo () ((bar :accessor get-bar :initform 0 :initarg 
:bar :type symbol)))
#<STANDARD-CLASS FOO>
CL-USER> (make-instance 'foo :bar 'foo)

:BAR is an invalid initarg to INITIALIZE-INSTANCE for #<STANDARD-CLASS 
FOO>.
Valid initargs: #().
    [Condition of type SIMPLE-ERROR]

Restarts:
   0: [ABORT] Return to Slime toplevel.

Backtrace:
   0: (CCL::CHECK-INITARGS NIL (:BAR FOO) T)
   1: (CCL::%MAKE-STD-INSTANCE)
   2: (#<CCL::STANDARD-KERNEL-METHOD MAKE-INSTANCE (STANDARD-CLASS)> 
#<STANDARD-CLASS FOO>)
   3: (#<CCL::STANDARD-KERNEL-METHOD MAKE-INSTANCE (SYMBOL)> FOO)
   4: (CCL::CALL-CHECK-REGS MAKE-INSTANCE)
   5: (SWANK::EVAL-REGION "(make-instance 'foo :bar 'foo)" T)
   6: (SWANK:LISTENER-EVAL "(make-instance 'foo :bar 'foo)")
   7: (CCL::CALL-CHECK-REGS SWANK:LISTENER-EVAL)
   8: (SWANK:EVAL-STRING "(swank:listener-eval \"(make-instance 'foo 
:bar 'foo)\")" "CL-USER")
   9: (FUNCALL SWANK:EVAL-STRING)
   10: (SWANK::CALL-WITH-SLIME-STREAMS #<SWANK::SLIME-INPUT-STREAM 
#x537D076> #<TCP-STREAM (SOCKET/15) #x537D236> #<TWO-WAY-STREAM input 
#<SWANK::SLIME-INPUT-STREAM #x537D076>, output #<TCP-STREAM (SOCKET/15) 
#x537D236> #x537D03E> #<Compiled-function FUNCALL #x5081DDE> 
(SWANK:EVAL-STRING "(swank:listener-eval \"(make-instance 'foo :bar 
'foo)\")" "CL-USER"))
   11: (SWANK::READ-FROM-EMACS)
   12: (SWANK::SERVE-ONE-REQUEST)
   13: (SWANK::REQUEST-LOOP #<TCP-STREAM (SOCKET/12) #x537D4B6>)
   14: (SWANK::ACCEPT-ONE-CLIENT #<CCL::LISTENER-SOCKET #x537A456>)
   15: (SWANK::ACCEPT-LOOP #<CCL::LISTENER-SOCKET #x537A456> NIL)
   16: (CCL::RUN-PROCESS-INITIAL-FORM (#<COMPILED-LEXICAL-CLOSURE 
#x5379E76>))
   17: (Anonymous Function #x50FC336 (#<COMPILED-LEXICAL-CLOSURE 
#x5379E76>))
   18: (Anonymous Function #x50F7C3E)

So no matter what I do, I can't redefine the class so that :bar is an 
:initarg for the bar slot.
Sadly, I can't reproduce this behavior in a fresh image for a more 
useful bug report, although I tried.
I'll try to keep the image open...

Sven