preece@ccvaxa.UUCP (11/06/85)
> I don't understand? Using the car or cdr field of a CONS cell as a > floating point number does not stop you from getting garbage because > you still cannot operate on that location. If you do you will change > it's value everwhere that it is referenced (LISP avoids copying lists > if possible) /* Written 8:18 pm Oct 23, 1985 by petera@hcrvax.UUCP in > ccvaxa:net.lang */ ---------- You can operate on it in place to exactly the same extent as any other LISP object. If the CAR of that CONS cell were a pointer to a boxed number and you changed its value by changing that pointer you would have exactly the same propagation considerations. In general, in most LISPs, changing the CAR of a CONS cell would be done by building a new CONS cell with the new values and linking using it for the result of the operation. You would NOT change the boxed number it points at, since that might be shared by other references. Most LISPs have some representation for integers that involves no garbage. Really. Most of them WILL return T for (eq 4 (+ 2 2)). Really. ---------- > If we use the standard (setq) function such as: (setq 'n (+ n 1)) > then we have created a new value for 'n and the old one is still > hanging around. This is regardless of how we store the pointer/float as > a union somewhere. ---------- The value cell of n, on an implementation using immediate integers, will have an integer value in it. Nothing else will point to that word (except via the conceptualization that the value is a pointer to itself). Anything with the value 0x2 will contain 0x2, NOT a pointer to a value stored somewhere else. Your further argument about intermediate values in partially evaluated lambdas I didn't follow completely, but different LISPs have different rules for scoping, binding, and simultaneity in various kinds of expressions. -- scott preece gould/csd - urbana ihnp4!uiucdcs!ccvaxa!preece