Compilation implications

[Jon L White <jonl@lucid.com>]

And thanks to you too, David, for putting some time into this.
[Note that I've dropped cl-compiler off the cc list.]

Some Questions.

-- Your code for the 'reconstruction-form' method never adds anything 
   to the 'allocation-args' -- did you excise some TI-specific parts? 
   or what is this ever supposed to be besides nil?

-- What is 'finalize-inheritance'?  is it to fix up "stubs" that had
   been created as "placeholder" classes merely so that some type
   dispatch could make reference to the class?

-- Why do you use 'slot-exists-p-using-class' instead of 'slot-exists-p'?
   The class argument you are passing in for 'object' is simply the 
   value obtained from (class-of object) anyway?

-- When you ran into some trouble with  the form:

    (DEFMETHOD MAKE-INSTANCE ((CLASS (EQL (FIND-CLASS 'MY-CLASS))) ...) ...)

   was it because your DEFMETHOD treats this form essentially the same as

    (DEFMETHOD MAKE-INSTANCE ((CLASS (EQL '#.(FIND-CLASS 'MY-CLASS))) ...) ...)

   Does your macro expander for DEFMETHOD call EVAL to get the object,
   rather than returning a form to be evaluated later?


I agree with you very much that the reasonable way to handle potentially
circular data is to allocate an object first (and "register" it in the 
corresponding compiler or binary-loader table) and _then_ create the 
several components.  As Moon points out, there may be some classes of
objects for which this componentwise protocol is unsatisfactory -- 
objects which must, for example, be "massaged" after creation by one or
the other initialization protocol (or both).  For these, circularities 
could be an intractable problem; but for classes for which the fasdmp-
mixin is suitable, there should be no problem.  I hope it's true that 
the vast majority of cases can be handled by fasdmp-mixin.



-- JonL --