Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!wuarchive!uunet!tut.cis.ohio-state.edu!sei.cmu.edu!fs7.ece.cmu.edu!o.gp.cs.cmu.edu!ram From: ram+@cs.cmu.edu (Rob MacLachlan) Newsgroups: comp.lang.lisp Subject: Re: Eternal fixnum question (was Re: GET / GETF warning.) Message-ID: <1991May7.172635.20431@cs.cmu.edu> Date: 7 May 91 17:26:35 GMT References: <4580@skye.ed.ac.uk> <1991May1.015534.27054@cs.cmu.edu> <4613@skye.ed.ac.uk> Sender: netnews@cs.cmu.edu (USENET News Group Software) Organization: School of Computer Science, Carnegie Mellon Lines: 37 In article <4613@skye.ed.ac.uk> jeff@aiai.UUCP (Jeff Dalton) writes: >>>[2] (let ((x 5)) (eq x x)) ; CLtL II p 104 >This is a good explanation (just what I was looking for), and it >suggests a number of examples. However, it's not clear that >expressions such as [2] are among them. I think that the real problem is that simple examples such as these are trying to demonstrate that pointer identity doesn't work on numbers. The justification for this restriction is that it helps numeric code, but as you point out, these particular examples are not helped (and are rather silly). In fact, CMU CL will optimize [2] to T, even if an arbitrary expression is substituted for "5". >When I was thinking about mixed examples before, it seemed to me >that a compiler might follow the rule "if a pointer is ever needed, >allocate on the heap". This would be a reasonable rule were it not for loops and seldom-taken branches (like error checks.) Consider: (let ((sum 0.0)) (dotimes (i (length vec)) (incf sum (aref (the (simple-array single-float (*)) vec) i)) (when (> sum 1e3) (error "Sum too big: ~S" sum))) sum) In this case, we have a pointer use in an inner loop that is in reality never used. It is also possible to have pointer uses outside of a loop when the variable is referenced in a loop. For example, if we wanted to accumulate the sum in a global variable, then it would be a good idea to do: (let ((sum *global-sum*)) ...summing loop... (setq *global-sum* sum)) Robert MacLachlan (ram+@cs.cmu.edu)