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).

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...)