🚀 go-pugleaf

What to you think? Loops without using loops?

a loop:

for(i=0;i<10;i++)
{
  stuff
}

Looping with out a loop

no_loop(0,10);

no_loop(int start, int end)
{
    if(start != end) {
        stuff
        no_loop(start+1,end);
    }
}

I haven't tested this but you get the idea.

In article <3151B47F.70FD@connix.com>,
Scott Hawley  <shawley@connix.com> wrote:
>What to you think? Loops without using loops?
>
>a loop:
>
>for(i=0;i<10;i++)
>{
>  stuff
>}
>
>Looping with out a loop
>
>no_loop(0,10);
>
>no_loop(int start, int end)
>{
>    if(start != end) {
>        stuff
>        no_loop(start+1,end);

recursion! ouch! I'd hate to do a no_loop(1,1000000000);

>    }
>}
>
>I haven't tested this but you get the idea.

How do you intend to pass ``stuff'' to the no_loop function? I think you are a
little confused about C! :)

For this to be of any practical use, one should be able to supply an arbitrary
statement block in the place of stuff. One way to do this is to define no_loop
as a pre-processor macro. This has been done since the dawn of C for creating
idioms for traversing linked list and other data structures. I have recently
seen a program written in 1980 which contains an example.


	#define no_loop(S,E) for (;(S) < (E);(S)++)

You then do:

	int x, y = 4;

	no_loop(x, y) {
		printf("%i\n",x);
	}

The first argument to no_loop must be an lvalue, and it gets incremented, so
this does not have the semantics you were looking for in your own definition of
the no_loop() function.

How this is better than using an explicit for() loop is not clear to me. Such a
macro is useful when you have to traverse some complex data structure. In my
own hash-table module, I define a macro called 'hash_for', which will step
through all the elements inserted into the hash table and set the specified
node pointer to each one in turn. The reason I have this is because the hash
table is somewhat involved. There have to be two nested loops to do the
traversal. The outer one steps through the array of chains, and the inner one
traverses any non-empty chain. Written explicitly, the code looks ugly and
would confound any program that has to many such traversals in various places.

Instead, all I have to do is:

	hash_for(hash_table_ptr, data_ptr) {
		/* process data_ptr */
	} hash_rof;


-- 

In article <4isrhqINNpol@keats.ugrad.cs.ubc.ca> c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku) writes:

   recursion! ouch! I'd hate to do a no_loop(1,1000000000);

Only because you are not familiar with compilers which perform
tail-recursion elimination.

Nick Barnes, speaking for himself

In article <NICKB.96Mar22141650@abel.harlqn.co.uk>,
Nick Barnes <nickb@harlequin.co.uk> wrote:
 >In article <4isrhqINNpol@keats.ugrad.cs.ubc.ca> c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku) writes:
 >
 >   recursion! ouch! I'd hate to do a no_loop(1,1000000000);
 >
 >Only because you are not familiar with compilers which perform
 >tail-recursion elimination.

Actually I am, but I overlooked that.

By the way, some of those compilers will not eliminate the recursion if you
don't turn on the optimization flag. The programmer is making the correct
execution of the code depend on his expectation that the tail recursion will be
eliminated by the compiler, instead of eliminating it himself. A large loop
will blow the stack without the presence optimization, or use an inordinate
amount of memory.
-- 

Scott Hawley (shawley@connix.com) wrote:
> What to you think? Loops without using loops?

> a loop:

> for(i=0;i<10;i++)
> {
>   stuff
> }

> Looping with out a loop

> no_loop(0,10);

> no_loop(int start, int end)
> {
>     if(start != end) {
>         stuff
>         no_loop(start+1,end);
>     }
> }

This is how iteration is done in Scheme.  The above example
is tail-recursive.  In such cases, Scheme systems optimize
this to iterative code.

> I haven't tested this but you get the idea.

--
________________________________________________________________
John E. Howland        url: http://www.cs.trinity.edu/~jhowland/
Computer Science     email: jhowland@ariel.cs.trinity.edu
Trinity University   voice: (210) 736-7480
715 Stadium Drive      fax: (210) 736-7477
San Antonio, Texas  78212-7200

On Thu, 21 Mar 1996, Scott Hawley wrote:

> What to you think? Loops without using loops?

  You can certainly use recursion instead of looping iteratively, but 
there are space and time concerns associated with recursion.  Of course, 
there's always tail recursion optimization, which is basically just looping 
behind the programmer's back. :-)  There are a number of languages which use 
recursion and/or generate-and-test paradigms to replace iterative loops 
(mostly logical and functional languages like Lisp, Miranda, Prolog, 
Mercury, ML, Haskell, etc.).
  When I'm programming in C, I tend to use for(;;) and while() and their 
ilk a lot because that's the idiom C uses, and I use recursion only when the 
problem is best expressed recursively.

/**James Robinson***********************            
  "If a fatal error occurs, the program should not be allowed to continue."
 -- Oracle Pro*C User's Guide         *************james-robinson@uiowa.edu**/

In article <NICKB.96Mar22141650@abel.harlqn.co.uk>
           nickb@harlequin.co.uk "Nick Barnes" writes:

>In article <4isrhqINNpol@keats.ugrad.cs.ubc.ca> c2a192@ugrad.cs.ubc.ca (Kazimir
> Kylheku) writes:
>
>   recursion! ouch! I'd hate to do a no_loop(1,1000000000);
>
>Only because you are not familiar with compilers which perform
>tail-recursion elimination.

More to the point I am familiar with compiler (certainly C compilers) that
don't perform tail-recursion elimination. While any such compilers are
a possibility the recursive approach is trouble.

-- 
-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------

In <NICKB.96Mar22141650@abel.harlqn.co.uk>, nickb@harlequin.co.uk (Nick Barnes) writes:
>In article <4isrhqINNpol@keats.ugrad.cs.ubc.ca> c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku) writes:
>
>   recursion! ouch! I'd hate to do a no_loop(1,1000000000);
>
>Only because you are not familiar with compilers which perform
>tail-recursion elimination.

Which they of course do by converting the recursion to a loop.

Dan Hicks
http://www.millcomm.com/~danhicks/

John E. Howland wrote:
> 
> Scott Hawley (shawley@connix.com) wrote:
> > What to you think? Loops without using loops?

In J the concept of "each" does away with loops alltogether.

You place all the items you want to operate on in arrays. 
Character arrays, numerical arrays or boxed arrays.

You then apply all kinds of operations on these arrays.

With "each" you do not have to specify or test for beginnings
or ends of anything. 

As for the developer there is no need to think about how this
is actually performed in the machine.

In the past this was a burden for the machine because developers could
write code so fast that the machines had a difficult time executing
all that was given to them.

It is only recvently that the machines have become fast enough to 
take the likes of J that lets developers write in a few statements
things that used to make the machine operate on for a long time.

J does not care how many elements an array has when you write

a plus b

if you as a developer have defined 

plus=.+
a=.2
b=.3

with a and b as scalars or 

a=. 1234 23$i.111111

J still allows you to write 

a plus b

No loops need to be defined. 

-- 
/Gosi
bjornhp@simi.is Bjorn Helgason Spitalastig 4 101 Reykjavik Iceland 354 
562 5441
http://www.jsoftware.com

1kldfk;df;gj

Scott Hawley (shawley@connix.com) wrote:
: What to you think? Loops without using loops?

: a loop:

: for(i=0;i<10;i++)
: {
:   stuff
: }

: Looping with out a loop

: no_loop(0,10);

: no_loop(int start, int end)
: {
:     if(start != end) {
:         stuff
:         no_loop(start+1,end);
:     }
: }

: I haven't tested this but you get the idea.

>: What to you think? Loops without using loops?

>: Looping with out a loop
>
>: no_loop(0,10);
>
>: no_loop(int start, int end)
>: {
>:     if(start != end) {
>:         stuff
>:         no_loop(start+1,end);
>:     }
>: }
>
>: I haven't tested this but you get the idea.

Here's a guy who would rather recurse than loop. I don't mean to be rude, but 
this is typical of C programmers. Why not write it so it says what it does? 
Who benefits from your tricks? 

I write this from the standpoint of someone who has spent a career poking 
through stuff like the above -- writing it weird just so you can say you 
didn't do ____. 

I'm really tired of it. 
........................................................................

In article <4jq2en$g2q@news.cais.com> dlabell@paltech.com "David Labell" writes:

>Here's a guy who would rather recurse than loop. I don't mean to be rude, but 
>this is typical of C programmers.

Using recursion in preference to a loop is rather atypical of C
programmers. However there is nothing wrong in discussing alternatives in
a thread such as this, especially when related to languages with a more
functional bias.

>Why not write it so it says what it does? 

For real code that is generally thr correct approach.

>Who benefits from your tricks? 

Anybody who is interested in a broader understanding of programming issues.

>I write this from the standpoint of someone who has spent a career poking 
>through stuff like the above -- writing it weird just so you can say you 
>didn't do ____. 
>
>I'm really tired of it. 

Nobody was advocating the use of it (at least not in C).

-- 
-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------

Scott Hawley wrote:
> 
> What to you think? Loops without using loops?
> 
> a loop:
> 
> for(i=0;i<10;i++)
> {
>   stuff
> }
> 
> Looping with out a loop
> 
> no_loop(0,10);
> 
> no_loop(int start, int end)
> {
>     if(start != end) {
>         stuff
>         no_loop(start+1,end);
>     }
> }
> 
> I haven't tested this but you get the idea.

In J I frequently use something like 

empty  keyra each vector

where vector contains number of elements which may or may not be 
referenced in the verb keyra or subsequently called verbs. Its size
is used as a counter.

vector could look like this:

vector=.i.111

Keyra could look like this:

keyra=: 3 : 0
try. runni ''
catch. empty''
end.
)

each makes the verb keyra be called as many times as there are elements
in vector. 

empty makes sure I do not get any display of any results.

each and empty are utilty verbs in J

runni is a verb called by keyra and is actually the one I want to 
call but if it breaks down somewhere I dont want the operation to
halt but to continue with the next element of vector.

I do not specify any start nor end


-- 
/Gosi , bjornhp@simi.is 
http://www2.simi.is/~gosi
http://www.jsoftware.com

In article <4jq2en$g2q@news.cais.com>,
dlabell@paltech.com (David Labell) wrote:

 >>: Looping with out a loop
 >>
 >>: no_loop(0,10);
 >>
 >>: no_loop(int start, int end)
 >>: {
 >>:     if(start != end) {
 >>:         stuff
 >>:         no_loop(start+1,end);
 >>:     }
 >>: }
 >>
 >>: I haven't tested this but you get the idea.
 >
 >Here's a guy who would rather recurse than loop. I don't mean to be rude,
 >but this is typical of C programmers. Why not write it so it says what it
 >does? 
 >
 >Who benefits from your tricks? 

People who write developer tools for debugging blown stacks and corrupted
heaps :-).

Data dependent errors are the production programmer's worst nightmare;
especially as they normally occur at 3:00 AM with some panicked operator
who can't read english on the other end of the line.

I avoid recursion in _any_ production code, no matter how I can minimize
the stack frame.

Recursion can make for visually appealing and simplified code, but in real
terms they're nothing but trouble unless you can absolutely positively
guarantee a finite, known level stack depth.

Nothing can compare to debugging some clever code in the middle of the
night due to the fact that you've got in-order data strung out on a binary
tree, traversed by recusion :-/.

---
The above are my own opinions, and not those of my employer.

In <AD87DB279668D9F74@mcdiala15.it.luc.edu>, VArase@varase.it.luc.edu (Verne Arase) writes:
>I avoid recursion in _any_ production code, no matter how I can minimize
>the stack frame.
>
>Recursion can make for visually appealing and simplified code, but in real
>terms they're nothing but trouble unless you can absolutely positively
>guarantee a finite, known level stack depth.

I use recursion where recursion is appropriate.  (In my mind, using 
recursion to avoid a simple loop ISN'T appropriate, though.) 
Unconditionally avoiding recursion is just as ill-advised as abusing it 
-- some of the worst code I've seen is code where recursion would have 
made a big difference (had the programmer understood the concept).

On the other hand, recursing is something I do a lot of, fairly 
unconditionally.  8-)

Dan Hicks
http://www.millcomm.com/~danhicks/

In article <AD87DB279668D9F74@mcdiala15.it.luc.edu>
           VArase@varase.it.luc.edu "Verne Arase" writes:

>Recursion can make for visually appealing and simplified code, but in real
>terms they're nothing but trouble unless you can absolutely positively
>guarantee a finite, known level stack depth.

An O(log N) stack depth is generally not a problem. I guess you could say
that is finite because there are typically practical upper bounds to N.

-- 
-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------

    In article <AD87DB279668D9F74@mcdiala15.it.luc.edu>
    VArase@varase.it.luc.edu "Verne Arase" writes:
    >> Recursion can make for visually appealing and simplified code,
    >> but in real terms they're nothing but trouble unless you can
    >> absolutely positively guarantee a finite, known level stack
    >> depth.

>>>>> "Lawrence" == Lawrence Kirby <fred@genesis.demon.co.uk> writes:
    Lawrence> An O(log N) stack depth is generally not a problem. I
    Lawrence> guess you could say that is finite because there are
    Lawrence> typically practical upper bounds to N.

Tail recursion is implemented by all non-stupid compilers the same way
as the imperative (goto) version.  Gcc will do this, whether or not
your favorite compiler will is a different matter.

No stack problems at all.

Kelly

thus spake David Labell in comp.lang.misc...

. Here's a guy who would rather recurse than loop. I don't mean to be rude, but 
. this is typical of C programmers. Why not write it so it says what it does? 

isn't it really rather more typical of lisp programmers...?
--
xian the desk lisard -- cdahello@comp.brad.ac.uk
                             [ red, pink and blue, but mainly purple ribbons ]
thirty years ago how the words would flow with passion and precision
            ---                     you had them all on your side, didn't you?

In article <oun34tm3c7.fsf@lynx.cs.byu.edu>,
Kelly Hall <hall@cs.byu.edu> wrote:
>>>>>> "Lawrence" == Lawrence Kirby <fred@genesis.demon.co.uk> writes:
>    Lawrence> An O(log N) stack depth is generally not a problem. I
>    Lawrence> guess you could say that is finite because there are
>    Lawrence> typically practical upper bounds to N.
>
>Tail recursion is implemented by all non-stupid compilers the same way
>as the imperative (goto) version.  Gcc will do this, whether or not
>your favorite compiler will is a different matter.
>
>No stack problems at all.

I have seen several people claim that GCC does proper optimization
of tail calls, but also claims to the contrary.  I decided to test
it for myself with this little tail recursive program:

  #include <stdlib.h>
  #include <stdio.h>
  
  int evenp(long i)
  {
    if (i==0) return 1;
    return oddp(i-1);
  }
  
  int oddp(long i)
  {
    if (i==0) return 0;
    return evenp(i-1);
  }
  
  int main(int argc, const char *argv[])
  {
    if (argc!=2) 
      puts("Usage: oddp <number>");
    else if (oddp(abs(atol(argv[1]))))
      puts("Number is odd.");
    else
      puts("Number is not odd.");
    return 0;
  }

The sad truth is that this program, compiled with GCC 2.7.0 (-O3),
blows the stack when tested with a number large enough.  Tail calls
within a single function seems to be optimized, though, but this
limitation is really too restrictive for people who want to program
in a functional style (or translate functional programs to C.)

On the other hand, Suns unbundled C compiler (v3.0.1) seems to
handle this example well, as well as mutual recursion between
different compilation units.  The DEC OSF/1 compiler (v3.11 on an
Alpha) also does OK, but only within a single compilation unit.
More data points?

All in all, I don't think it's wise to count on tail call
optimization if you are aiming for portable C code.
--
Rickard Westman                   |   "Beware of the panacea peddlers:
Dept. of Computer Science         |    Just because you wind up naked 
Linköping University              |    doesn't make you an emperor."  
Sweden                            |              - Michael A Padlipsky

In article <oun34tm3c7.fsf@lynx.cs.byu.edu>,
Kelly Hall <hall@cs.byu.edu> wrote:
>>>>>> "Lawrence" == Lawrence Kirby <fred@genesis.demon.co.uk> writes:
>    Lawrence> An O(log N) stack depth is generally not a problem. I
>    Lawrence> guess you could say that is finite because there are
>    Lawrence> typically practical upper bounds to N.
>
>Tail recursion is implemented by all non-stupid compilers the same way
>as the imperative (goto) version.  Gcc will do this, whether or not
>your favorite compiler will is a different matter.
>
>No stack problems at all.

I have seen several people claim that GCC does proper optimization
of tail calls, but also claims to the contrary.  I decided to test
it for myself with this little tail recursive program:

  #include <stdlib.h>
  #include <stdio.h>
  
  int evenp(long i)
  {
    if (i==0) return 1;
    return oddp(i-1);
  }
  
  int oddp(long i)
  {
    if (i==0) return 0;
    return evenp(i-1);
  }
  
  int main(int argc, const char *argv[])
  {
    if (argc!=2) 
      puts("Usage: oddp <number>");
    else if (oddp(abs(atol(argv[1]))))
      puts("Number is odd.");
    else
      puts("Number is not odd.");
    return 0;
  }

The sad truth is that this program, compiled with GCC 2.7.0 (-O3),
blows the stack when tested with a number large enough.  Tail calls
within a single function seems to be optimized, though, but this
limitation is really too restrictive for people who want to program
in a functional style (or translate functional programs to C).

On the other hand, Suns unbundled C compiler (v3.0.1) seems to
handle this example well, as well as mutual recursion between
different compilation units.  The DEC OSF/1 compiler (v3.11 on an
Alpha) also does OK, but only within a single compilation unit.
More data points?

All in all, I don't think it's wise to assume that tail call
optimization is done by the typical C compiler.

--
Rickard Westman                   |   "Beware of the panacea peddlers:
Dept. of Computer Science         |    Just because you wind up naked 
Linköping University              |    doesn't make you an emperor."  
Sweden                            |              - Michael A Padlipsky

In article <oun34tm3c7.fsf@lynx.cs.byu.edu> hall@cs.byu.edu "Kelly Hall" writes:

>>>>>> "Lawrence" == Lawrence Kirby <fred@genesis.demon.co.uk> writes:
>    Lawrence> An O(log N) stack depth is generally not a problem. I
>    Lawrence> guess you could say that is finite because there are
>    Lawrence> typically practical upper bounds to N.
>
>Tail recursion is implemented by all non-stupid compilers the same way
>as the imperative (goto) version.  Gcc will do this, whether or not
>your favorite compiler will is a different matter.
>
>No stack problems at all.

Code that relies on compiler optimisations (which C doesn't guarantee) to
even work at all is at best highly suspect and at worst plain broken. In
some cases it is company policy to compile with optimisations turned off,
this should not cause code to blow up.

-- 
-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------

In <4jq2en$g2q@news.cais.com>, dlabell@paltech.com (David Labell) writes:
>I write this from the standpoint of someone who has spent a career poking 
>through stuff like the above -- writing it weird just so you can say you 
>didn't do ____. 

All that time and you still haven't learned that "recur" is the verb 
meaning "to perform recursion"?  "Recursing" is what you do when
you once again read "clever" code.

Dan Hicks
http://www.millcomm.com/~danhicks/

[Lawrence Kirby]

|   In some cases it is company policy to compile with optimisations turned
|   off, this should not cause code to blow up.

that may explain more than we want to know about the software business.

#<Erik 3037663843>
-- 
education is for people who can't handle reality the hard way

In article <19960405T033124Z@gyda.ifi.uio.no>
           enag@gyda.ifi.uio.no "Erik Naggum" writes:

>[Lawrence Kirby]
>
>|   In some cases it is company policy to compile with optimisations turned
>|   off, this should not cause code to blow up.
>
>that may explain more than we want to know about the software business.

In sone cases it makes sense to favour reliability over speed. OTOH
optimisers are quite reliable these days.

-- 
-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------

VArase@varase.it.luc.edu (Verne Arase) wrote:

>I avoid recursion in _any_ production code, no matter how I can minimize
>the stack frame.

I wholly agree.  I do the same for my production code.  It is
especially important when you're producing mission critical
applications!
---
Rajendra Singh, B. Sc. (Rajendra_Singh@msn.com)
"What is understood need not be discussed." - Loren Adams

In article <4k3fvg$p1o@loki.tor.hookup.net>,
Rajendra Singh <Rajendra_Singh@msn.com> wrote:
>VArase@varase.it.luc.edu (Verne Arase) wrote:

>>I avoid recursion in _any_ production code, no matter how I can minimize
>>the stack frame.

>I wholly agree.  I do the same for my production code.  It is
>especially important when you're producing mission critical
>applications!

I dunno.  I am unable to convince myself that recursion is not the best way to
do things like a merge sort.  I just make sure that I can prove it's no
more than log(n), and that it's sane.  For most of my apps, this means that
I'd run out of memory to allocate sortable objects before the stack space
would be an issue.

-s
-- 
Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach.
C/Unix wizard -- C/Unix questions? Send mail for help.  No, really!
FUCK the communications decency act.  Goddamned government.  [literally.]
The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html

In <19960405T033124Z@gyda.ifi.uio.no>, Erik Naggum <enag@gyda.ifi.uio.no> writes:
>[Lawrence Kirby]
>
>|   In some cases it is company policy to compile with optimisations turned
>|   off, this should not cause code to blow up.
>
>that may explain more than we want to know about the software business.

What it "explains" is that (a) optimizing compilers are all too often 
quite buggy, and (b) most languages (including C, C++, et al) don't 
provide adequate facilities to allow programmers to sufficiently specify
INTENT so that invalid (from the programmer's viewpoint) optimizations 
don't occur occasionally.

Dan Hicks
http://www.millcomm.com/~danhicks/

>>>>> "Rickard" == Rickard Westman <ricwe@ida.liu.se> writes:
    Rickard> The sad truth is that this program, compiled with GCC
    Rickard> 2.7.0 (-O3), blows the stack when tested with a number
    Rickard> large enough.  Tail calls within a single function seems
    Rickard> to be optimized, though, but this limitation is really
    Rickard> too restrictive for people who want to program in a
    Rickard> functional style (or translate functional programs to C).

Hmm - I never bothered to try mutually (tail)recursive functions.  I'm
not really surprised that Gcc doesn't handle the calls well.

    Rickard> On the other hand, Suns unbundled C compiler (v3.0.1)
    Rickard> seems to handle this example well, as well as mutual
    Rickard> recursion between different compilation units.  The DEC
    Rickard> OSF/1 compiler (v3.11 on an Alpha) also does OK, but only
    Rickard> within a single compilation unit.  More data points?

I tried this test with both the HP C compiler (the development
compiler, with most patches) and GCC 2.6.3.  Both seemed to run out of
gas at about the same rate.  So I think that HP (and FSF) might stand
to improve their handling of mutual (tail) recursion.

    Rickard> All in all, I don't think it's wise to assume that tail
    Rickard> call optimization is done by the typical C compiler.

I stand corrected.  So why haven't more C compiler folks added this
useful optimization?

Kelly

a-cnadc@microsoft.com (Dann Corbit) writes:
> In article <3151B47F.70FD@connix.com>, shawley@connix.com says...
> >
> >What to you think? Loops without using loops?
> >
> >a loop:
> >
> >for(i=0;i<10;i++)
> >{
> >  stuff
> >}
> >
> >Looping with out a loop
> >
> >no_loop(0,10);
> >
> >no_loop(int start, int end)
> >{
> >    if(start != end) {
> >        stuff
> >        no_loop(start+1,end);
> >    }
> >}
> >
> >I haven't tested this but you get the idea.
> Yes, recursion can be used to loop "without a loop".
> There is no practical advantage to this method.
> The recursive version has 10 function calls to add
> to its overhead.

Actually, since this function is tail recursive, any good compiler
will optimize the recursive function call to a jump to the start of
the program block, effectively making this a loop.  Note that non-tail
recursive functions will not be subject to this optimization, however.

Steve Zdancewic
Carnegie Mellon University

Lawrence Kirby <fred@genesis.demon.co.uk> wrote:
>In article <oun34tm3c7.fsf@lynx.cs.byu.edu> hall@cs.byu.edu "Kelly Hall" writes:
>
>>>>>>> "Lawrence" == Lawrence Kirby <fred@genesis.demon.co.uk> writes:
>>    Lawrence> An O(log N) stack depth is generally not a problem. I
>>    Lawrence> guess you could say that is finite because there are
>>    Lawrence> typically practical upper bounds to N.
>>
>>Tail recursion is implemented by all non-stupid compilers the same way
>>as the imperative (goto) version.  Gcc will do this, whether or not
>>your favorite compiler will is a different matter.
>>
>>No stack problems at all.
>
>Code that relies on compiler optimisations (which C doesn't guarantee) to
>even work at all is at best highly suspect and at worst plain broken. In
>some cases it is company policy to compile with optimisations turned off,
>this should not cause code to blow up.
>
>-- 
>-----------------------------------------
>Lawrence Kirby | fred@genesis.demon.co.uk
>Wilts, England | 70734.126@compuserve.com
>-----------------------------------------

-- 

----------------------------------------------------------------------------
VISION AUTOMATION
Taufiq Habib
habit@delphi.com
Office (619) 930 1974
Beeper (800) 796 7363  x103-6118