Jerzy Karczmarczuk wrote:
> 
> Of course, Smalltalk has its deficiencies. You can't (apparently) 
> define and use an optimized tail-recursive method; if 
> 
> anObject doesSomethingWith: params
> 
>    ... "folk dance and whatever. At the end, conditionally:"
> 
>    ^ self doesSomethingWith: newParams
> 
> each call instance will stack the receiver, and finally we get a squeak:
> "low memory" or something alike, if the depth is too large. In Scheme (say)
> 
> (funct obj params)
>  ... ;; which calls at the end
>     (funct obj newparams)
> 
> will turn in constant space. And that is how the *strict* iteration is defined
> in functional languages. The arguments are not stacked, they smash the
> previous ones. In principle a good optimizing Smalltalk compiler might do
> that as well, although I cannot be categorical. Any opinion of The Gurus?

I remember this being discussed here on the list some time back.  It
sounded like it would not be difficult to change the system to enable
tail recursion optimization, though I don't recall whether a compiler
change would be sufficient, or a VM change would be necessary in the
general case.  (I think a compiler change is sufficient, at least, for
self-recursive methods, but possibly not for mutual recusion.)  As to
whether it would be a good idea, the consensus seemed to be that it
would interfere too much with the debugger's strengths.  (Tail
recursion optimization effectively erases all record of intermediate
calls, making it much harder (or impossible) to back-trace the
execution of a running program.)

-Jesse