[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: DECLARE-TYPE-FREE (Version 1)
- To: Moon@STONY-BROOK.SCRC.Symbolics.COM
- Subject: Issue: DECLARE-TYPE-FREE (Version 1)
- From: Jon L White <jonl@lucid.com>
- Date: Thu, 22 Sep 88 19:20:19 PDT
- Cc: GLS@Think.com, CL-Cleanup@sail.stanford.edu
- In-reply-to: David A. Moon's message of Sun, 18 Sep 88 16:22 EDT <19880918202212.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
A number of comments on this first draft:
----
I raised this issue at the Fort Collins meeting last November, suggesting
that it was an unintended aberration in CLtL. But Guy Steele quickly
defended it, and promised to write down his objection to the "ALLOW"
interpretation and mail them out (this was in a plenary session, and was
only partially relevant to the item under discussion.) To date, I don't
recall seeing his objections, but he should cough them up now or forever
hold his peace.
----
The current statement of "the problem" isn't really right. Until you wrote
it in this message, I don't remember people saying that they thought locally
type declarations were "not valid Common Lisp". Rather, they were thought
to be un-useful declarations, since the compiler is forbidden to treat
variable references differently based on cognizance of that declaration
[i.e. declaration can affect "bindings", but not "references"]. In fact,
none of the half-dozen or so implementations I've tried this on during the
past year issued any warning or error in such cases. This is not to say
that at least some people didn't think it was "invalid"; merely that the
statistical sample leans toward the "un-useful" side. [Please, gang, no
puns on that last sentence.]
----
The proposal says:
Change the phrase "affects only variable bindings" to "concerns variable
bindings." . . .
Is this really an improvement? the change seems to have the exactly the
same potential for misinterpretation as the original. Admittedly, with
the subsequent clarification, one is less inclined to think so; then again,
one might simply think the specification is inconsistent.
----
Surely, the matter must be related somewhat to the issue of how a compiled
local variable will be implemented. Pdp10 MacLisp would "home" fixnum and
flonum variables on stacks distinct from the one normally used for function
call frames (or "activation records" or whatever you favorite buzz word for
this concept). These alternate stacks -- the FXPDL and FLPDL -- were
incapable of holding data not of the declared type; so in that world:
(let ((x <some-value>))
(declare (fixnum x))
(somehow-ignore x)
(setq x 5)
...)
would be compiled radically differently from:
(let ((x <some-value>))
(locally (declare (fixnum x))
(somehow-ignore x)
(setq x 5)
...))
since the former implementationally restricts the value of <some-value>
to be a fixnum, whereas the latter permits it to be, for one instant at
the time of binding, any old random type. The S1/NIL implementation
expected to have a "pdlnum" scheme similar to pdp10 MacLisp's, so I would
think that CLtL's restriction is due to Guy's experience in trying to
accommodate this implementational technique. At the very least, the
proposal needs to show cognizance of the difference between a compiler's
type information propogation (and inferencing) and of the constraints
imposed by the compiler's choice of "slots" to hold variables' values.
However, I don't believe any vendor today except Lucid employs this
implementational technique; and Lucid has already long since jumped
ahead on this mater to give the locally type declarations their
obvious meaning -- namely, semantically equivalent to wrapping a
(the <type-specifier> ...) around each reference to the variable.
[Incidentally, in Lucid's implementation, the semantic difficulty
refered to in the previous paragraph -- about "affecting the binding"
-- manifests itself as a performance pessimization rather than any
inconsistency or incorrectness in the code. so it says here.]
Some thoughts like these ought to be in the proposal before it is
submitted to the committee as a whole.
-- JonL --