[Openmcl-devel] Code that causes problems in OpenMCL, not other Lisps

[Gary Byers]

On Sat, 26 Feb 2005, Ralph Richard Cook wrote:

> I don't know the proper incantations in the CLHS to know exactly where
> this is a problem, in OpenMCL or other Lisps. This small code doesn't
> have a problem in Clisp on windows, SBCL on Linux, SBCL or LispWorks on
> Mac.
>
> I put the following code in testslot.lisp:
>
> (defclass testslot () ((myslot :accessor myslot :initform nil)))
>
> (defclass tester () ((myts :accessor myts :type testslot :initarg :myts
> :initform nil)))
>
> (defmethod initialize-instance :after ((tester tester) &rest initargs)
>      (declare (ignore initargs))
>      (unless (myts tester) (setf (myts tester) (make-instance
> 'testslot))))
>
> (setf mytester (make-instance 'tester))
>
> On openmcl I get:
>
> Welcome to OpenMCL Version (Beta: Darwin) 0.14.2-p1!
> ? (load "testslot.lisp")
>  > Error in process listener(1): The value NIL, derived from the
> initform NIL, can not be used to set the value of the slot MYTS in
> #<TESTER #x637674E>, because it is not of type TESTSLOT.
>  > While executing: CCL::%SHARED-INITIALIZE
>  > Type :POP to abort.
> Type :? for other options.
> 1 >
>
> Should this work?

The consequences of trying to store a value (NIL, in this case) that's
not of the slot's specialized type (TESTSLOT, in this case) are undefined,
so ignoring the error or detecting and signalling it are equally correct
behaviors.  I think that it's more useful to signal an error when the
object clearly is of the wrong type.

(Note that, sometimes, the "right" type is something like (OR NULL TESTLOT)).

I think that checking slot type on assignment/initialization is A Good
Thing, though it's been pointed out that it's possible (via CHANGE-CLASS
and similar means) to violate type constraints in other ways.




> Thanks,
> Richard Cook
>