Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!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: <54109@ti-csl.CSNET>
Date: 13 Jul 88 18:21:56 GMT
References: <901@td2cad.intel.com> <3061@rpp386.UUCP> <395@proxftl.UUCP> <53374@ti-csl.CSNET> <464@proxftl.UUCP>
Sender: news@ti-csl.CSNET
Reply-To: gateley@mips.UUCP (John Gateley)
Distribution: na
Organization: TI Computer Science Center, Dallas
Lines: 59

In article <464@proxftl.UUCP> bill@proxftl.UUCP (T. William Wells) writes:
>2) Pointed out that the only compiler that anyone says can do
>   tail recursion, gcc, applies to a single processor, and that
>   my work requires porting to over a hundred compilers.

There are many compilers which do tail recursion: several Common Lisp compilers
do, and by definition the programming language Scheme is tail recursive.

>4) Pointed out that tail recursion is equivalent to a while loop
>   and that is the preferred method of coding this kind of
>   algorithm. [The implied context is C, I'd not say this for
>   some other languages.]

Perhaps the name tail recursion is misleading, a function call in tail
recursive position does not need to be a recursive call. In this c program:
main() /* does a semicolon go here? */
{
   if (some-c-exp) {
         foo(1,2,3);
         }
   else {
         bar(4,5,6);
        };
}
(pardon my c, I do not usually use this language).
both the call to foo and the call to bar are tail recursive, even though they
are not a call to main. The difference between this and recursive example
is that both of them do a "jump" to the function, instead of a subroutine call,
but in a recursive call, the argument space is reused (instead of pushing on
the stack). This means that tail recursion is not equivalent to while loops.

>   technique. Unless, of course, one is a gcc chauvinist, in
>   which case, one's opinions are irrelevant.

I am worse than a gcc chauvinist (actually I have never used gcc): I am a Lisp
chauvinist.

>4) Strlen has absolutely no business being coded recursively.
>   And while a recursive strlen algorithm might be an
>   interesting exercise in alternative thinking, it is simply
>   the wrong way to do it. It is just as silly as those example
>   factorial algorithms which I suspect mislead the individual
>   who wrote the strlen. An algorithm implements an idea; the
>   idea of strlen is that of the number of characters in a
>   string.  The recursive implementation of it simply fails to
>   capture this property, except, perhaps, to a mathematician, or
>   someone else who counts using Peano's axioms.

To me, the recursive implementation of strlen tells me exactly what it does;
a while loop would require extra effort on my part to understand. This may
be our different coding styles, but it is not a reason to call recursion
silly. (I am not a mathematician, nor can I use Peano's axioms)

>like that?) [B.T.W., doesn't a continuation have a context, and
>isn't that context equivalent to an activation record?]
Yes, kindof, I think. But what I was describing was continuation passing style
which is a different thing. In continuation passing style, a program is
converted into an equivalent program where every call is in a tail recursive
position. This makes the program more amenable to some optimizations. (Not
just the tail recursive ones).