[Openmcl-devel] OpenMCL MOP Issue

[Brent Fulgham]

Gary,

Thanks for the explanation, but I'm still confused by the first part  
of your response:

On Feb 17, 2007, at 5:07 PM, Gary Byers wrote:

> (defclass foo ()
>  ((a :type (member 12 17 21))))
>
> (defclass bar (foo)
>  ((a  :type (member 9 17 23))))
>
> (slot-definition-type (car (class-direct-slots (find-class 'bar))))
> => (member 9 17 23)
>
> (slot-definition-type (car (class-slots (find-class 'bar))))
> => (integer 17 17)
>
> The (effective) type of a slot is the intersection of its direct type
> and the direct types it inherits from its ancestors.  There are
> several (an infinite number of ...) equivalent ways of specifying this
> type in the example:
>
> (and (member 12 17 21) (member 9 17 23))
>
> (eql 17)
>
> (satisfies 17p)
>
> etc.
>
> but it's a computed value that may or may not be EQL to the direct- 
> slot-definition's TYPE.

Coming from my admittedly rudimentary Lisp background, I am somewhat  
surprised that this:

? (defclass b ()
      ((foo :type boolean)))
#<STANDARD-CLASS B>

... reports itself as this:

? (slot-definition-type (first (class-slots (find-class 'b))))
(MEMBER T NIL)

... even though the '"type" was explicitly declared as 'boolean'.

Consider a type enclosing a larger set:

? (defclass a ()
((foo :type integer)))
#<STANDARD-CLASS A>
? (slot-definition-type (first (class-slots (find-class 'a))))
INTEGER

This makes sense to me, because the type 'integer is what I  
stipulated for the slot; I don't expect to see a return type defining  
the list of values, for example

(MEMBER 0 1 2 3 4 ... )

Is it just BOOLEAN that is defined as its two potential values, or  
are there other types that work this way?

> SINCE T is a member of the builtin types BOOLEAN and SYMBOL and since
> BOOLEAN is a subtype of SYMBOL (but not vice versa), BOOLEAN is a
> correct answer and SYMBOL is not under the test suite's  
> interpretation.

This seems like a valid argument to me -- I think OpenMCL's  
implementation is right in this case.

> In many cases (notably involving NUMBERs and ARRAYs in either  
> interpretation
> and involving T in ), there are many correct answers.  Idioms like
>
> (eq (type-of x) expected)
>
> should generally be avoided or viewed with suspicion.

I'll keep that in mind in the future.

Thanks for your (as always) helpful and detailed explanations.

Regards,

-Brent