Re: Detecting endless recursion?

nmm1@cus.cam.ac.uk (Nick Maclaren) writes:


> 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.


Many languages (e.g., Scheme or SML) specify that tail-recursion must
be done in constant space. These also specify GC or other automatic
memory reclaiming method, so relying on both is no problem.
Obviously, the programmer has to understand the limitations of both
tail-recursion and GC. Since the original poster invented his own
language, he is free to speficy what the assumptions are.


> 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 :-)


Now you're trolling. Scheme has many debugging tools that don't break
tail-recursion (or GC).


> 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.


Languages that requires you to look at coredumps to understand where
you went wrong were outdated 20 years ago.


Torben Mogensen

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