Re: [spr8701] Accesing CLOS objects from C?

[smh@franz.com (Steve Haflich)]

[This matter has been assigned the tracking identifier "spr8701".
Please refer to it in any followup communication.  Also, be sure
to cc bugs@franz.com so that if I am unavailable someone else will
be able to respond.]

   Subject: Accesing CLOS objects from C?
   Date: Fri, 25 Jun 93 16:23:56 +0900
   From: Kazunobu Kashiwabuchi <buchi@ntttsd.ntt.jp>

   I am making a c function which can be a CLOS-method or a part of it.
   To establish this functionality, CLOS objects should be accessed
   directly from C functions.
   Unfortunately, unlike other basic LISP objects(e.g. LIST, FIXNUM), the
   structure of CLOS-objects are not described in lib/misc/lisp.h. 

   Does anyone know how to access CLOS-objects from C?
   Or am I doing dirty work??

Thanks for pointing out that the structure of STANDARD-INSTANCE
objects is not contained in the file lisp.h.  I will try to have this
fixed in a future release.  However, there are good reasons why the
structure cannot be described completely for C.  The main reason is
that CLOS is described (through the Metaobject Protocol) in terms of
itself, and therefore many of the details of representation can be
customized or overridden by programs.  This is very different than for
all the other types of objects implemented by Lisp.

However, here are some basics that may give you what you need.

Any object that is a STANDARD-INSTANCE is represented similar to a
SIMPLE-VECTOR of length 2 (although the type code is different and the
length field not present).  You can't use SVREF from lisp on a
STADNARD-INSTANCE.  Instead, use EXCL::STANDARD-INSTANCE-REF.

  Element 0 of a STANDARD-INSTANCE is the `wrapper' of the class which
is a SIMPLE-VECTOR.  Element 4 of the wrapper is the instance's CLASS
object, which of course is itself another STANDARD-INSTANCE.

  Element 1 of a STANDARD-INSTANCE is a SIMPLE-VECTOR of
instance-allocated slots.  The tricky thing is figuring the index of
any particular slot in that vector, since that is computed at
class-finalization time and depends on all the superclasses of the
class.  (Unfortunately, the MOP function SLOT-DEFINITION-LOCATION
isn't implemented in 4.1.)  I _think_ in the default case the instance
slots will occur in the reverse of the order of the list of slot
definition objects returned by CLOS:CLASS-SLOTS.

I won't bother describing the representation of class-allocated slots
here.

   I think the easiest way is that at first CLOS-object is cut into basic
   LISP object by CLOS-methods and then passed into C functions and the
   return values are composed again into CLOS-object. But I think this 
   will cost a lot of overhead. I am also interested at this point. Any
   comment is appreciated.

This is analogous to the distinction between `by reference' and `by
value' in languages like C.  If you pass the contents of individual
slots to your foreign function, then you aren't passing the
STANDARD-INSTANCE to C at all, and therefore the question of
representation is irrelevant.  All accesses to slots can be done with
normal CL functions (e.g.  SLOT-VALUE and (SETF SLOT-VALUE), or else
individual slot accessors).  Whether this will impose unacceptable
overhead depends on your particular application.  I suspect that _if_
the overhead is acceptable, then it is desirable _not_ to try to
manipulate standard instances directly from C.  Your code will
probably be easier to understand and maintain.