in reply to Re: Re: Re: Iterating & Playing with Caller's Pads
in thread Iterating & Playing with Caller's Pads

So how does something for for (@array) { ... } keep track of it's state? Somehow *that* knows where it is. I recall that the hash accessors values/keys alter the hash but the list operators don't appear to do that (I just ran perl -MDevel::Peek -e "@a = qw(hello make my sheep into cherries); for (@a) { Dump(\@a)" to demonstrate to myself that for() doesn't alter the the array anyway. Oh yeah, and these operators also work on lists which don't even have an AV construct so duh, yeah I guess that makes sense. (smacks forehead)

I guess all I can think of is that while(scalar ..) and related's actual OP tracks that. I think what you want to do is use B::Generate to get a handle to a current opcode and then hang the list state off that somewhere... (not that I know if that's even possible, I'm just thinking about this as I type this).

Replies are listed 'Best First'.
Re:(5) Iterating & Playing with Caller's Pads
by shotgunefx (Parson) on Sep 27, 2002 at 14:42 UTC
    One thing I started doing was hacking Want to include an ITERATIVE context. The author had given me ideas on how and I may finish it yet but this seemed cleaner than examining the op tree.

    -Lee

    "To be civilized is to deny one's nature."
      How would you identify iterative context? (Tell me and we might get it implemented...)
        Excuse my ignorance as I am still very green on perlguts, but my thinking was that you could look at the ops before and after the call to see if you were called between and op_enterloop and op_leaveloop.

        I had run this by the author of Want.pm and he suggested something like the want_boolean function in Want.xs, but to look for OP_AND and it also needs to check that (o->op_next->op_type == OP_LEAVELOOP).

        I still think that in theory this take seems more correct.

        -Lee

        "To be civilized is to deny one's nature."