[Openmcl-devel] Slot :type and :initform catch-22

[Gary Byers]

On Mon, 5 Jan 2004, bryan o'connor wrote:

> > The function CCL::%SHARED-INITIALIZE is looking at the wrong local
> > variable: it binds NEWVAL to the value associated with the initform,
> > then checks the type of another (unrelated) varable (NEW-VALUE).
>
> was a fix for this bug checked into CVS?  i get a similar type
> problem when compiling cl-ppcre.  i tried making changes based
> off your mail, but i may have misunderstood.
>

There are basically two reasons why one might get type errors during
SHARED-INITIALIZE (which is implemented in a function called
CCL::%SHARED-INITIALIZE).

1) A slot has a type constraint and (a) an initarg or (b) an initform
violates that constraint.  Getting errors in these cases is irritating,
but I think that it's ultimately A Good Thing.

2) Due to a bug that was reported a couple of days ago,
%SHARED-INITIALIZE typechecks and (complains about) the value a local
variable whose name is similar to the value of the initform but will
(IIRC) always be NIL at this point, so legitimate cases of 1b don't
occur (and spurious ones do).

<http://clozure.com/cgi-bin/viewcvs.cgi/ccl/level-1/l1-clos.lisp.diff?r1=1.4&r2=1.5>

shows the change that I did commit a couple of days ago, honest!

To apply this, you need to grab a new version of l1-clos.lisp, do a
? (compile-ccl)
an
? (xload-level-0) ; if you don't already have a current ppc-boot[.image]

and build and save a lisp image as usual.

If the updated %SHARED-INITIALIZE is in effect, then it's either case (1)
(a valid complaint about a type declaration) or some other bug that bears
further investigation.  (I suppose that it could be an incorrect fix to
case (2), but that certainly looks correct to me.)

I think that the known cases can be distinguished by looking at the
stack frame of %SHARED-INITIALIZE when a type error such as this one
occurs (e.g., via:

1> (:f 0)

).  The local variable named FOUNDP will have a value of the form
(:KEYWORD VALUE) if the slot's initarg was provided and will be
NIL otherwise.  If the value doesn't match the declared type of
the slot (yes, IWBNI the TYPE-ERROR included the slot and class
names and printed this information when it was signaled), then
there's an error in the caller; otherwise, if the slot initform
doesn't match the declared type of the slot, there's an error
in the class definition, otherwise ... there's an error in the
implementation.

> thanks,
>
> 	...bryan
>
>
> ? (asdf:oos 'asdf:load-op :cl-ppcre)
>  > Error in process listener(1): value NIL is not of the expected type
> FIXNUM.
>  > While executing: CCL::%SHARED-INITIALIZE
> 1> (:b)
> (F0135920) : 0 "CCL::%SHARED-INITIALIZE" 764
> (F0135930) : 1 NIL NIL
> [...]
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>