Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!rutgers!bellcore!tness7!killer!pollux!ti-csl!mips!gateley
From: gateley@mips.csc.ti.com (John Gateley)
Newsgroups: comp.misc
Subject: Re: Basics of Program Design
Message-ID: <53374@ti-csl.CSNET>
Date: 6 Jul 88 18:47:39 GMT
References: <901@td2cad.intel.com> <3061@rpp386.UUCP> <395@proxftl.UUCP>  <430@proxftl.UUCP>
Sender: news@ti-csl.CSNET
Reply-To: gateley@mips.UUCP (John Gateley)
Distribution: na
Organization: TI Computer Science Center, Dallas
Lines: 65

In article <430@proxftl.UUCP> bill@proxftl.UUCP (T. William Wells) writes:
>[...]
>our code is regularly compiled with. Relying on compilers to do
>tail recursion optimization would be slitting our own throats.
>[...]
>Sorry, but using purely tail recursive routines does not save
>time for this programmer. Anywhere you would use tail recursion,
>I'd automatically code a while loop.  (See below for why.) This
>[...]
>Also, another real-world point: recursive routines in general
>need to be used carefully, to avoid excess resource consumption.
>As an example, I recently translated a rather complicated parsing
>routine from SCHEME to C. In the translated version were several
>recursive routines. One of the recursive routines was left alone,
>the greatest depth of recursion was the length of a grammar rule
>and removing the recursion would have been a real pain.  Another
>got fixed (even though it required extensive recoding) because it
>was not possible to bound the stack usage. Our customers WILL
>NOT let us chew resources with wild abandon.
>[...]
>efficient coding becomes second nature. Then you will naturally
>write efficient programs and as a matter of course will not do
>stupid things like writing strlen() recursively.

The tail-recursion debate has been going on for a while, and I would
like to defend tail recursion, recursion, and optimizations in general
against the points made above. First: tail recursion has been only
discussed as a "true" recursive call optimization in these postings.
It also applies to many non-recursive and indirectly recursive calls.
Tail recursion optimizations serve several more purposes than what has
been brought out here: it does not require pushing a return address on
the stack (no stack growth, this is the optimization that has been discussed
here); it allows more efficient argument passing (in the self-recursive
case, all you have to do is change the arguments on the stack, not push
new ones); it eliminates the need for saving register variables on the
stack; and probably several more that I dont know about. I prefer these
optimizations to take place. It has been mentioned that it is hard to
debug with a tail-recursion optimizing compiler. I disagree and I use
one every day.

As for recursion: it is a tool just like while loops. It is a useful
abstraction: many algorithms are much more simple in a recursive than
non recursive form (my opinion of course). I feel that in order to get
the most out of a language, it should have good tools (including recursion).
It is up to the compiler writers to make those tool perform well (including
being efficient). For example, there is a simple transformation which
completely removes the stack from a recursive program (translating the
program into continuation passing style). This is useful for compiler
writers: they can use it where appropriate to make the program execute
more efficiently.

I have a story which is similar to some that have been posted. In college,
one of my homework assigments was to determine if a graph was connected.
The graph was represented as a array with 1's for edges. I thought that
recursion was terribly inefficient, so I just multiplied the matrix against
itself the neccesary number of times. I also did it recursively. Guess which
one was faster! The recursive one of course.

I do not feel that recursion and/or tail-recursion are bad things. They
are extremely powerful tools, and like all tools (especially extremely
powerful ones) they must be used with care. But, if you think about it,
just about any programming language tool must be used with care.

John Gateley
The above statements are my opinions.