[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: LOAD-TIME-EVAL (Version 6)
- To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Subject: Issue: LOAD-TIME-EVAL (Version 6)
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Thu, 22 Sep 88 12:37 EDT
- Cc: Gregor.pa@Xerox.COM, dussud@lucid.com, sandra%defun@cs.utah.edu, eb@lucid.com, CL-Cleanup@SAIL.STANFORD.EDU, cl-compiler@sail.stanford.edu
- In-reply-to: <880921155806.5.KMP@GRYPHON.SCRC.Symbolics.COM>
- Line-fold: No
Date: Wed, 21 Sep 88 15:58 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Well, let me say up front that this description is absolutely unacceptable
to me because of the verbiage about destructive modification.
Also, I am concerned about how the "right thing" can be done with the
env argument in the case of
(EVAL-WHEN (EVAL COMPILE LOAD)
(DEFUN FOO (X) '(X #,(SQRT 3))))
In a file compiler, the #, must read in a way that is acceptable to the
compiler's runtime environment (compile to core) and the compiler's file
environment (compile to file). And this decision must be made at
readtime.
Of course this doesn't work and has never worked.
If instead you wrote:
(EVAL-WHEN (EVAL COMPILE LOAD)
(DEFUN FOO (X) #,`(X ,(SQRT 3))))
and #, expanded into a LOAD-TIME-VALUE expression, then the compile to
core operation could treat the LOAD-TIME-VALUE special form in one way
and the file compiler could treat the LOAD-TIME-VALUE special form
another way and things would work nicely as a natural result of the
accessibility of the lexical environment from the special form.
You should be more explicit that what you are actually arguing for is
the removal of #, from the language. You're also proposing to add a
new feature with very complicated but useful semantics, LOAD-TIME-VALUE,
to the language. Pretending that you're fixing #, only obscures the issues.