Re^2: Iterative vs Recursive Processes

Using caller you are supposed to be able to generate a complete stack backtrace

Wouldn't:

Be aware that the optimizer might have optimized call frames away before "caller" had a chance to get the information. That means that caller(N) might not return information about the call frame you expect it do, for "N > 1". In particular, @DB::args might have information from the previous time "caller" was called.

(from caller's docs) let you out of that particular hole? Tail recursion would just be another case to add to the existing ones. Not entirely backwards compatable, but not so bad as to disallow the concept I would have thought...

Comment on Re^2: Iterative vs Recursive Processes

Replies are listed 'Best First'.
Re: Re^2: Iterative vs Recursive Processes by tilly (Archbishop) on May 13, 2003 at 14:46 UTC
Good point. However even so I would argue against turning it on naively. You see in Perl part of cleaning up a call-frame is destroying temporary lexical variables and undoing invocations of local. When the things destroyed are objects that may have side-effects in their DESTROY methods (see ReleaseAction for an example where this happens) then trying to optimize tail-recursion creates a significant change in what the code does. Which brings us to another theme. A lot of the theory folks argue for side-effect free programming (this is what "functional programming" really means - as opposed to the bad meme that I started) because (among other things) it gives the compiler far greater opportunity to optimize and reorder how things happen. (Proponents argue that it also makes big programs easier to understand.) However we naive humans find avoiding side-effects a difficult discipline, which makes a lot of theoretical optimizations very hard to apply in practical languages. As Larry Wall said, optimization is a form of cheating, which is why you always get caught. And the more free-form the language is, the more requirements you put on the compiler, and the easier it is to catch it out when you try to cheat. :-)	[reply]
Re^4: Iterative vs Recursive Processes by adrianh (Chancellor) on May 13, 2003 at 16:17 UTC
However even so I would argue against turning it on naively. Oh I agree. It's not something that can be globally switched on for perl 5 (and the lousy speed for subroutine calls makes tail-recursive code less appealing anyway). I just don't think `caller` is a problem :-) When the things destroyed are objects that may have side-effects in their DESTROY methods (see ReleaseAction for an example where this happens) then trying to optimize tail-recursion creates a significant change in what the code does. True, but naive scope-related DESTROY code is going to be in trouble when we get proper GC in perl6 anyway :-)	[reply] [d/l]
Re: Re^4: Iterative vs Recursive Processes by tilly (Archbishop) on May 13, 2003 at 16:26 UTC
True, but naive scope-related DESTROY code is going to be in trouble when we get proper GC in perl6 anyway :-) True, and did I say that I was happy about this...? :-P	[reply]