in reply to Re: map vs for (not the usual breed)
in thread map vs for (not the usual breed)

sub x { $_++ for @_; @_[1,4] = (2,5); &z; }

You're probably right (in your doubt that this may be feature rather than a mal-feature - I see arguments for both possibilities), but ability to modify @_ and &-form of sub call still existing apart, I suppose that if one really wanted to do this sort of manipulations, then the way to go would be would be by means of magic goto, which would avoid the call altogether, and thus using the stack for... err... well, nothing.

Replies are listed 'Best First'.
Re^3: map vs for (not the usual breed)
by shmem (Chancellor) on Jun 27, 2007 at 15:09 UTC
    Well no... it would not avoid the call, but fake the current call as that one.

    The magic goto really introduces a bit more (or another) overhead, in that it looks back and forth, saves @_, carefully disassembles the current stack frame and replaces it with the one of the called sub, and then restores @_. The magic goto is most useful to replace the current subroutine, mainly to eliminate AUTOLOAD from what caller() might report. So in replacing &z with goto &z we are trading localizing @_ against disassembly of a whole sub frame. I don't know what's "cheaper".

    &z is really a shorthand of z(@_) which additionally overrides the argument prototypes of sub z (if any).

    --shmem

    _($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                                  /\_¯/(q    /
    ----------------------------  \__(m.====·.(_("always off the crowd"))."·
    ");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}
      I don't know what's "cheaper".

      I didn't know that magic goto would imply all that work... in fact I've seen it used to handcraft tail recursion, and indeed I wasn't suggesting its generalized use, since it should always be a specific tool to use in specific situations: other than the canonical AUTOLOAD one, I've been using it to switch repeatedly between two "states" that were defined in own subroutines none of which really meant to ever return. Upon a condition, one of them would goto the other.