Re: Detecting endless recursion?

nmm1@cus.cam.ac.uk (Nick Maclaren)
22 Jan 2004 23:09:29 -0500

          From comp.compilers

Related articles
[6 earlier articles]
Re: Detecting endless recursion? torbenm@diku.dk (2004-01-16)
Re: Detecting endless recursion? witness@t-online.de (Uli Kusterer) (2004-01-16)
Re: Detecting endless recursion? witness@t-online.de (Uli Kusterer) (2004-01-16)
Re: Detecting endless recursion? Martin.Ward@durham.ac.uk (Martin Ward) (2004-01-16)
Re: Detecting endless recursion? vbdis@aol.com (2004-01-16)
Re: Detecting endless recursion? joachim.durchholz@web.de (Joachim Durchholz) (2004-01-18)
Re: Detecting endless recursion? nmm1@cus.cam.ac.uk (2004-01-22)
Re: Detecting endless recursion? lex@cc.gatech.edu (Lex Spoon) (2004-01-22)
Re: Detecting endless recursion? torbenm@diku.dk (2004-01-31)
Re: Detecting endless recursion? witness@t-online.de (Uli Kusterer) (2004-01-31)
Re: Detecting endless recursion? witness@t-online.de (Uli Kusterer) (2004-02-01)
Re: Detecting endless recursion? witness@t-online.de (Uli Kusterer) (2004-02-01)
Re: Detecting endless recursion? joachim.durchholz@web.de (Joachim Durchholz) (2004-02-01)
[14 later articles]
| List of all articles for this month |

From: nmm1@cus.cam.ac.uk (Nick Maclaren)
Newsgroups: comp.compilers
Date: 22 Jan 2004 23:09:29 -0500
Organization: University of Cambridge, England
References: 04-01-050 04-01-086 04-01-119
Keywords: debug, comment
Posted-Date: 22 Jan 2004 23:09:29 EST

Joachim Durchholz <joachim.durchholz@web.de> writes:
|> Torben Ęgidius Mogensen wrote:
|>
|> >> my app just bombs because it runs out of memory (because my fake
|> >>stack keeps growing and growing). And the OS doesn't let me know it's
|> >>out of memory because it's happily paging out VM.
|> >
|> > It sounds like you are not implementing tail calls properly.
|>
|> Since the tool is going to be educational, I assume that the users
|> will be able to halt the execution and inspect the stack state. In
|> this situation, tail call optimization is something that should not be
|> done: the users will complain that the tool has removed information
|> (all those intermediate stack frames that got eliminated due to tail
|> call optimization).


What does educational have to do with it? While tail recursion
removal has its advantages, any language/compiler/program that RELIES
on it is misdesigned at best. Inter alia, it has the following
problems (all of which I have seen in real life):


1: Unless tail recursion removal is specified in the language, you are
immediately relying on an implementation-dependent feature and so are
writing non-portable code. This is the same problem as relying on
garbage collection, writ small.


2: Recompile for debugging, or insert your own tracing of function
returns, and the program fails before it reaches the code you are
testing. The best 'solution' to this that I was told was to use a
supercomputer for debugging the codes you are intending to run on a
low-end PC :-)


3: Don't recompile for debugging, and try to unpick a dump, and you
are faced with the problem of failing in a utility function called
from everywhere and not a clue of how you got there. So you add some
tracing to find that out, and you mutually recurse into problem 2.


Like many advanced optimisations, the downside of tail recursion
removal is a risk of seriously reduced debuggability. While the price
MAY be worth paying, it is NOT true that it is necessarily a good
idea. In particular, omitting it is NOT "not implementing tail calls
properly."


Regards,
Nick Maclaren.
[Scheme defines tail recursion into the language, and it seems to work
OK. -John]


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.