[Openmcl-devel] OpenMCL MOP Issue
bfulg at pacbell.net
Sun Feb 18 06:03:42 UTC 2007
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)
> 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)))
... 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)))
? (slot-definition-type (first (class-slots (find-class 'a))))
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
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
> 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.
More information about the Openmcl-devel