Compilation implications

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

re: [CLOS Chapter 3 stuff]

Hmm, well maybe portable code won't want to be using that just yet.


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

    Yes, the evaluation is being done at macro expansion time.  If that's not
    right, I'll need to change it.

A few things weigh against the evaluation being done at macroexpansion time:

  -- Lucid's DEFSTRUCT implementation does some of the work of the
     defstruct definition at macro-expansion time, and the rest at
     the subsequent evaluation time (when that macro-expanded form
     is finally evaluated).  This has caused numerous headaches, such
     as in trying to fully macroexpand a form like:
         (progn
            (defstruct foo a b c)
            (defstruct (bar (:include foo)) d e)
         )
     [The bug is that the second defstruct cannot be macroexpanded,
     because it cannot :include the first one until the first defstruct
     has been truly evaluated.]  Were it not for other constraints, we 
     probably would have fixed this long ago.  In summary, always have a 
     macroexpander return a "simple" program rather than "part program, 
     and part (constant) data containing pre-calculated evaluations."

  -- Treated as a program, the (FOO) in a specializer (EQL (FOO)) poses
     no special problems in cross-compiling; but treating it as a kind
     of constant designator (implying object creation at compile time)
     requires a tremendous amount more of the runtime class hierarchy
     to be "present and accounted for" in the cross-compiling environment.

  -- In PCL, Gregor took the "program" approach rather than the "data" one;
     Moon has gone on record favoring it too.  And although I dislike the
     approach taken for DEFCONSTANT by most implentations, it too favors
     the "program" approach.  It sure would be nice for eql specializers
     not to have to fall into the horrible controversy surrounding
     compiled constants (i.e., those other than DEFCONSTANT constants).


-- JonL --


P.S. This part of the discussion seemed relevant to the cl-compiler group
     also;  messages dealing primarly with CLASS semantics, however,  
     probably don't need to be cc'd there.