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.