Re: Re: Re: Iterative vs Recursive Processes

I agree that if you want to optionally change caller's behaviour, then you can get tail-recursion to work.

However I am having extreme difficulty in seeing how, even in principle, one could make your more complex approach work. One could save memory by compressing the information in the caller stack. But I fail to see how one could regenerate the intermediate results in a complex computation on demand without redoing the computation - and that only works if you readily know (which you don't in Perl) that the computation is side-effect free.

Comment on Re: Re: Re: Iterative vs Recursive Processes

Replies are listed 'Best First'.
Re: Re: Re: Re: Iterative vs Recursive Processes by hv (Prior) on May 12, 2003 at 20:31 UTC
For tail-recursion I'm not sure what intermediate results you would ever need to recreate? Maybe it's just the time of day, but I can't off the top my head think of any way to get at that information in current perl. Let me take a simple example: `sub factorial { my $n = shift; my $mult = @_ ? shift : 1; return $mult if $n < 2; return factorial($n - 1, $mult * $n); }` [download] Ah, now I see the problem: I had forgotten about the 'invisible' caller() arguments, `@DB::args`, which are used (for example) by Carp to show the parameters each subroutine was called with in a stack trace. Ok, scratch that approach. :) Hugo	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re: Re: Re: Re: Iterative vs Recursive Processes
by hv (Prior) on May 12, 2003 at 20:31 UTC

For tail-recursion I'm not sure what intermediate results you would ever need to recreate? Maybe it's just the time of day, but I can't off the top my head think of any way to get at that information in current perl.

Let me take a simple example:

  sub factorial {
    my $n = shift;
    my $mult = @_ ? shift : 1;
    return $mult if $n < 2;
    return factorial($n - 1, $mult * $n);
  }
[download]

Ah, now I see the problem: I had forgotten about the 'invisible' caller() arguments, @DB::args, which are used (for example) by Carp to show the parameters each subroutine was called with in a stack trace. Ok, scratch that approach. :)

[reply]
[d/l]
[select]