[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: Sat, 7 Jan 89 01:04 EST
- Cc: Jon L White <firstname.lastname@example.org>, Common-Lisp-Object-System@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU
- In-reply-to: <2809040762-4991819@Kelvin>
Date: Thu, 5 Jan 89 19:06:02 CST
From: 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
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.
What I had in mind was ((LAMBDA (object) ...code...)). But I like your
suggestion of evaluating the form in an environment where * is bound to the
object better. Other people should check me on this, it might just be that
you appealed to my sense of hackish kludgery.
It would be nicer if we could just use a function, but the last proposal I
saw for what you could use as constants in COMPILE-FILE said you could not
use functions. We could use a LAMBDA expression, I suppose.
> Should I evolve the proposal I sent out the other day along these lines?
Yes, I would like to see that.
I'll update it based on all the received comments as early as I can next week.