Re: tail call proposal [was: Re: tail recursion proposal]

[Stephen Adams <adams@martigny.ai.mit.edu>]

I have lost track of who originally said this:

 > > > I don't think that "stack debugging" and such are very good at
 > > > justifying a lack of proper tail recursion.  If programs use loops
 > > > where they would otherwise use tail recursion, then "stack debugging"
 > > > won't find a stack to debug either.  

I would like to point out that tail calls do not necessarily
make debugging more difficult.  Debugging information is a
programming environment issue.

As an example, the MIT Scheme interpreter has a `history'
mechanism which records tail calls.  If you use the MIT
Scheme debugger, the tail calls show up as "reductions", and
the non-tail calls as "subproblems".

The MIT Scheme implementation uses a constant (configurable)
amount of storage to maintain the history.  I could imagine
a more sophisticated implementation that keeps as much
information as possible and only releases storage when it is
required to make the illusion of running in finite space fit
within the actual space available.


I think it is poor form to use the term "tail recursion" as
in general it is undecidable if a tail call is recursive.
The fact that this term keeps cropping up makes me favour
the "pessimization" explanation.