Re: Compilation implications

[David N Gray <Gray@DSG.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
> it. 

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.