On Fri, 1 Feb 2002, Anthony Hannan wrote:

> In the block closure version, which uses stack frames for method
> contexts, I doubt the tailSend: bytecode would be any faster

It might be marginally faster through caching issues from using less stack
space. (Probably marginal, but it should be benchmarked.)

> The biggest drawback of tailSend:, I think, is losing the calling
> context when looking in the debugger.  It would just add to the
> confusion when trying to figure out a bug.

Agreed.

> But I guess there are some algorithms where the tail recursive version
> is nicer.  So I would vote for adding the tailSend: bytecode but requiring
> another language construct that invokes it, so you are aware of it (in
> the debugger).  I would not automatically convert all "send: +
> returnTop" to "tailSend:"

I want it to make it easier to write those algorithms. We've got closures,
with closures and tailcall come useful uses of continuations.

Debuggability is one of squeak's strengths. Wholesale replacement, other
than as an experimental test/benchmark, would be a bad idea.

BTW, what about tailcall out of a block?

foo:
  ^[^self bar]

Is that a different bytecode?

And thanks...

Scott