[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Issue: DECLARE-TYPE-FREE (Version 1)



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 --