[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: LOAD-TIME-EVAL (Version 3)
- To: Moon@Stony-Brook.SCRC.Symbolics.COM
- Subject: Issue: LOAD-TIME-EVAL (Version 3)
- From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Thu, 12 Nov 87 21:42 EST
- Cc: KMP@Stony-Brook.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
- In-reply-to: <19871112234843.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
(-: Well, I'm glad to see someone at least read the proposal. :-)
I'm not adverse to inviting the question. Why did we have a #, read
syntax? I can't think of any cases where it is necessary. Even in
cases where it occurs in embedded structure,
'(A B #,<expression>)
can be written
#,`(A B ,<expression>)
It's not even extra consing -- the loader's going to have to cons the
list anyway... Whether it's under user control seems to be a small
price to pay (unless I've confused myself somehow and there's more
going on here).
The examples from my Fortran->Lisp translator and from CLOS seem to both
be cases where the full power of #, is unnecessary. I'm willing to believe
there is another compelling case, but could not think of one the other
day when I tried.
I have no trouble keeping #, and #. straight, but I find that novices
I've taught get very confused by them. I think they are not as much alike
as people think (except as an accidental artifact of the cheapshot way
#, is typically implemented in the interpreter). I think the fact that
#, and #. cannot be distinguished in the interpreter is a major cause
of the confusion.
I -like- the idea that
(CADDR (CADDR (CADR '#'(LAMBDA (X) (+ X #,(SQRT 2))))))
should return #,(SQRT 2) rather than 1.4142135 because it might be that
my plans were to write the code back out and compile it in another
implementation with larger floating point precision. I want the #,
stuff processed at semantic analysis time even in the interpreter, never
at read time. Just because I READ something does not mean I plan to EVAL
it right away. That's the problem.
If you didn't process it at read time though, since there are still
holdouts who think you can write an interpreter which does no semantic
pre-pass, then executing QUOTE becomes very expensive (because you have
to check it for #, objects). So I expect people would object. So I'm
proposing not putting #, in QUOTE rather than proposing that EVAL work
harder when it finds a QUOTE expression. Am I missing something?
I kinda think that what I'm proposing is simpler (albeit incompatible).
I'm curious whether you disagree that this is simpler, and whether you
can show why (allegedly) simpler doesn't cut it.
I thought about just hashing this out with you privately, but we might
as well get this all into the record...