[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
misc. stuff
- To: Rees%YALE@SU-DSN, common-lisp@SU-AI
- Subject: misc. stuff
- From: Daniel L. Weinreb <DLW%SCRC-TENEX%MIT-MC@SU-DSN>
- Date: Mon, 04 Jul 1983 15:06:00 -0000
- In-reply-to: The message of 30 Jun 83 14:20-EDT from Jonathan Rees <Rees at YALE>
Date: Thu, 30 Jun 83 14:20:16 EDT
From: Jonathan Rees <Rees@YALE.ARPA>
[1] Will there be a unified index in the next edition of the manual? I
have the impression that Symbolics has decided that it is best to have
one index instead of four or five. I certainly agree.
Yes, we have. Actually, I think we now belive that it's best to have
both kinds, but the one at the back (the one that's easy to find) should be
a combined index. Guy, Jan Walker has figured out some good ways to do
this in Scribe.
[4] Pages 76 and 99: what is the lexical scope of the body of a macro
definition? I.e., where do free variables (and functions) get their
values? This needs clarification. E.g., what does the following mean?
(setq x 8)
(eval-when (compile) (setq x 2))
(let ((x 5))
(macrolet ((foo (z) `(+ ,z ,x)))
(foo 7)))
Does this evaluate to 9, 12, or 15? Does it matter whether the code is being
"interpreted" or "compiled"? Can the manual be written in such a way as to
let this be explicitly undefined?
Well, I think it's always the case that if you run around using
eval-when, things can behave differently "evaluted" than "compiled". I
definitely do not think things like this should be left undefined; this
is a fundamental issue of evaluation semantics. I think the only viable
possibility is that it is defined to return 15 evaluated and 9 compiled,
never 12.
[7] Page 244. Is READ-DELIMITED-LIST defined to side-affect the syntax
of its "char" argument in *READTABLE*, even if only temporarily?
Presumably it would be implemented by temporarily defining a
right-parenthesis-like readmacro character for "char", using
UNWIND-PROTECT or something of the sort. If such an implementation is
permitted, perhaps this should be mentioned.
I agree, since this is exactly how we were going to implement it (I
haven't gotten around to it yet).