[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Compilation implications
- To: "David A. Moon" <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Subject: Re: Compilation implications
- From: David N Gray <Gray@DSG.csc.ti.com>
- Date: Thu, 5 Jan 89 19:06:02 CST
- Cc: Jon L White <email@example.com>, Common-Lisp-Object-System@Sail.Stanford.edu, CL-Compiler@Sail.Stanford.edu
- In-reply-to: Msg of Thu, 5 Jan 89 18:43 EST from David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Sender: GRAY@Kelvin.csc.ti.com
> Probably it would be a better idea for MAKE-LOAD-FORM to return two
> values, where the first value is a form that will create the object and
> the second value is a form that will further initialize the object?
> This way the order of evaluation requirement is more explicit. It's
> upward compatible since the second value can be NIL if you don't need
Yes, that sounds good except for the problem of how to pass the object to
the second form.
> ... suppose we plug the object returned by
> the first form into the second form and do (schematically):
> (WHEN form1.2
> (EVAL (APPEND form1.2 (LIST (LIST 'QUOTE x1)))))
This reduces generality because the second form can't use optional
arguments, and it seems a little strange to say that the second value is a
form minus its last argument. I wonder if it wouldn't look nicer to just
designate a variable name to indicate where the object is to be plugged in?
For example, we might do:
(defmethod make-load-form ((object my-class))
(values `(allocate-mine ...)
`(init-mine * ...)))
where it is understood that the loader will bind * to the result of the
first form while evaluating the second. This follows the convention that
* is the result of the previous evaluation, so doesn't introduce a new
name to remember. Now that I think about it, I like this better than my
previous 4-value suggestion.
> Should I evolve the proposal I sent out the other day along these lines?
Yes, I would like to see that.