Re: Tailcall

[ramsdell@... (John D. Ramsdell)]

RLake@oxfam.org.uk writes:

> > Our concern here is error messages. A OP_TAILCALL leaves no trace of the
> > calling function, and that may be quite confusing in error messages.
> 
> > -- Roberto
> 
> That's a legitimate concern. On the other hand, it discourages the use of a
> natural form of recursive loop.
> 
> Could this possibly be a settable option? For example, if the debugging
> library is loaded, then you don't get tailcalls, but if it is you do...

The essence of a tail call is that it is a goto with arguments.  This
is the insight that Steele and Sussman gave us from the early days of
Scheme.  Since it is conceptually more similar to a goto rather than a
traditional procedure call, one should think of it as one does a goto.
No reasonable debuggers that I know of give the user a history of goto
targets when they present a stack trace, so why should anyone expect
that tail calls be part of a stack trace?

The problem is that people have an erroneous mental model of
computation in which invoking every procedures involves pushing
arguments on a stack, saving a return address, and then jumping to the
body of the procedure.  This is not how a tail call works.  There is
no need to put a return address on the stack.

If you misrepresent the concept of a tail call, you will produce
confusing in error messages.  Treat tail calls as gotos, and error
messages will enlighten users.

John