[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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:
(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.