[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Compilation implications
- To: David N Gray <Gray@DSG.csc.ti.com>
- Subject: Re: Compilation implications
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Thu, 5 Jan 89 16:32 EST
- Cc: Jon L White <jonl@lucid.com>, Common-Lisp-Object-System@Sail.Stanford.edu, CL-Compiler@Sail.Stanford.edu
- In-reply-to: <2809014625-3421425@Kelvin>
Date: Thu, 5 Jan 89 11:50:25 CST
From: David N Gray <Gray@DSG.csc.ti.com>
> Possibly, EQL specializers could raise this question. Upon re-reading,
> the language of 88-002R now seems a bit vague to me, and possibly open
> to misinterpretation, as to just when an EQL parameter specializer form
> is evaluated.
Yes, I ran into this when I wrote a method that looked something like
this:
(DEFMETHOD MAKE-INSTANCE ((CLASS (EQL (FIND-CLASS 'MY-CLASS))) ...) ...)
which wouldn't work without doing something like this:
(defmethod reconstruction-form ((object class))
(let ((class-name (class-name object)))
(if (and (symbolp class-name)
(eq (find-class class-name nil) object))
`(find-class ',class-name)
(error "Can't dump ~S to object file because it doesn't have a proper name." object))))
but I'm not sure if this is what the designers of CLOS had in mind.
The macroexpansion of defmethod must be wrong. The form inside the EQL
parameter specializer name should be evaluated at load time, not at
compile time. That's my opinion anyway; 88-002R doesn't say as far as
I can see.