[Openmcl-devel] OpenMCL MOP Issue

[Brent Fulgham]

I'm summarizing an e-mail exchange I had with Alexander Repenning off- 
list a couple of weeks ago.  I was hoping someone (read: Gary!) might  
have some ideas on how to approach this problem, or perhaps  
counterexamples of why OpenMCL's current behavior is correct.

The XMLisp (http://www.agentsheets.com/lisp/XMLisp/) library seems to  
have some problems on OpenMCL (at least the 1.1 version, I have not  
tried it with 1.0).  It appears to have fundamental differences in  
the way it works compared to MCL and LispWorks.

Alexander traced it down to the following apparent type problem:

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

(slot-definition-type (first (class-slots (find-class 'a))))

-> SYMBOL

or

(defclass c ()
    ((foo :type array)))

(slot-definition-type (first (class-slots (find-class 'c))))

-> ARRAY

BUT

(defclass b ()
    ((foo :type boolean)))

(slot-definition-type (first (class-slots (find-class 'b))))

OpenMCL-> (MEMBER T NIL)
MCL & LispWorks -> BOOLEAN

This is a problem.  (MEMBER T NIL) is a valid type definition but it  
is really hard to further process this. We are using this type  
information in XMLisp to implement CODECs, e.g.,

(defmethod PRINT-TYPED-ATTRIBUTE-VALUE (Value (Type (eql 'boolean))  
Stream)
   (prin1 (if Value "true" "false") Stream))


At least according to the MOP spec one would think slot-definition- 
type  returning something like BOOLEAN instead of (MEMBER T NIL)  
would be the preferred / correct way?


# Generic Function slot-definition-type slot the

# Returns the type of slot. This is a type specifier name. This is  
the defaulted value of the :type initialization argument that

# was associated with the slot definition metaobject during  
initialization.

To make the type dispatchable with the kind of method above, the type  
information needs to be a symbol.  Not sure if CLTM has any answers  
but it is certainly not good to have this kind of inconsistency.

Also BTW: (type-of t) -> SYMBOL (MCL & LispWorks) but BOOLEAN (OpenMCL)

Does this seem to be a problem in OpenMCL, or do you think the  
specifications are too loose in this area?

I'm not sure how best to approach the problem.  I might be able to  
kludge something in the XML library, but it would sure be nice if the  
standard dispatch mechanisms could handle this case properly.

Any ideas would be greatly appreciated.

Thanks,

-Brent


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20070217/67e1dd56/attachment.htm>