Re: slot-definition-type 1.0

The reason for the difference has to do with cases like:

(defclass a ()
   ((foo :type symbol)))

(defclass b (a)
   ((foo :type list)))

CLHS says (in the fourth bulleted paragraph of section 7.5.3) that the
type of a slot is the intersection of the slot's own and inherited
:TYPE slot definitions.  (In the example above, that intersection
is the type NULL, since NIL is the only thing that's both a SYMBOL
and a LIST.)

The AMOP basically just says that the value returned by
SLOT-DEFINITION-TYPE is the value of the :TYPE initarg used to
initialize the slot-definition initarg.  (In OpenMCL 1.0,
DIRECT-SLOT-DEFINITIONs have their type initialized from the initarg
in the DEFCLASS form (or via procedural class creation), while
EFFECTIVE-SLOT-DEFINITIONs have their type slots massaged and
canonicalized a bit (possibly to represent a type interesection and
partly to simplify type checking on assignment.)

I think that you can make the argument that massaging/canonicalizing
an EFFECTIVE-SLOT-DEFINITION's type slot violates what the AMOP says
about the relationship between :SLOT initarg vales and
SLOT-DEFINITION-TYPE's return value, but this canonicalization and
massaging might instead happen inside COMPUTE-EFFECTIVE-SLOT-DEFINITION,
and the AMOP requires that COMPUTE-EFFECTIVE-SLOT-DEFINITION implements
CLHS 7.5.3's slot inheritance behavior.  I don't think that you can
assume that an EFFECTIVE-SLOT-DEFINITION's type matches the :TYPE
initarg in the DEFCLASS form or class-creation call.

In the example above, would you prefer that

? (slot-definition-type (car (class-slots (find-class 'b))))

return LIST, or would something equivalent to the type specifier
NULL be more meaningful ?

If you accept "NULL or something equivalent" as being a better answer -
and that the effective slot definition may have a different type
attribute than the direct slot definition - then it seems that
(EQL NIL) or (AND LIST SYMBOL) would also be better answers than
LIST, though a simplified, canonical form like NULL would probably
be preferable.

Prior to 1.0, OpenMCL didn't try to do inheritance/intersection
on :TYPE initargs, so there was no canonicalization.  OpenMCL
does try to do type checking on slot initialization and assignment
when possible, so it's pretty desirable that an effective slot
definition's type is computed accurately.  "Canonicalizing"
a type named by DEFTYPE - such as MYTYPE - into its expansion
(STANDARD-OBJECT) is one side-effect of that process, but it's
a useful side-effect (in that that canonicalization doesn't have
to happen during typechecking.)

I'm about 85-90% convinced of the argument I'm making here; the
remaining 10-15% that's unconvinced has to do with whether your
expectation is reasonable and intuitive (and whether my argument
is obscure and/or unintuitive.)


On Thu, 3 Nov 2005, Kilian Sprotte wrote:

> Hi,
>
> I think I have found a bug in openmcl 1.0.
>
> If I am defining my custom type like this:
>
>    (deftype mytype () 'standard-object)
>
> and a class that uses it:
>
>    (defclass myclass () ((s :type mytype)))
>
> this form
>
>    (ccl:slot-definition-type (first (class-slots (find-class 'myclass))))
>
> returns:
>
>    ;; => STANDARD-OBJECT
>
> Openmcl 0.14.3 as well as sbcl would return MYTYPE here.
>
> I am not an accustomed bug reporter and new to this list,
> please tell me, if you need anymore information.
>

I think that I understand the issue, or at least part of it.

There's a separate issue related to DEFTYPE and the possibility
of type redefinition.  If that was the point that you were
trying to make, I mostly missed it.  (If you weren't thinking
of that issue, please forget that I mentioned it ...)

> Cheers,
>     Kilian
>
>
>
> _______________________________________________
> Bug-openmcl mailing list
> [email protected]
> http://clozure.com/mailman/listinfo/bug-openmcl
>
>