Colin Putney wrote:
> Whether a method is tail-recursive depends on
> how it was called in the first place, and what code executes between
> when it's invoked and when it recurses.

I think we're seeing different aspects of the issue: I'm wanting to
concentrate very narrowly on the stack frames that are left at the point
a method does the following:

TailCaller >> doSomething
  "... arbitrary stuff ..."
  ^ something someMessage.

Imagine execution has just entered SomeClass>>#someMessage. The stack
looks like

  UltimateCaller >> entryPoint
  TailCaller >> doSomething "hovering over a return-to-sender bytecode"
  SomeClass >> someMessage

Since all the middle frame will *ever* do when control is returned to it
is in turn return the accumulator to its caller, it can *always* safely
be elided without affecting the object-level meaning of a program at all.

The point where the difference *is* detectable is when reflective access
such as debugging or accesses to thisContext appear. (And even here,
there are options for improving the reflective presentation of the call
stack without harming the important object-level safety properties
tail-call frame elision gives you - for instance, see the literature on
"continuation marks")

The improved safe-for-space behaviour enables the construction of a new
class of programs that are not directly representable without elision of
redundant stack frames.

> And finally, Smalltalk does a lot less
> tail recursion than functional languages, if only because our
> collections are based on Array rather than Association.

Another reason is perhaps that using tail-recursion in a natural way
gets you into trouble very quickly, so people quickly learn not to do it ;-)

Regards,
  Tony
-- 
 [][][] Tony Garnock-Jones     | Mob: +44 (0)7905 974 211
   [][] LShift Ltd             | Tel: +44 (0)20 7729 7060
 []  [] http://www.lshift.net/ | Email: tonyg at lshift.net