|The stupid question is the question not asked|
(Using B::* to help follow execution order) Re: strange shift @_ problemby dchetlin (Friar)
|on Jan 19, 2001 at 10:37 UTC||Need Help??|
The lslice opcode comes before the shift in this output of B::Terse -- but keep in mind that B::Terse by default shows an optree, which is empatically not in execution order.
lslice is a BINOP, which means it has two children. The first child is the list of elements it will be grabbing (in this case, that comes from the range operator in list context, aka flip/flop in our opcodes above). The second child is the list from which we'll actually be slicing. The fact that the children are ordered that way is the reason the $_ etc. are evaluated first.
For an easier way to figure out what order things happen in, try the -exec option to Terse, like so:
perl -MO=Terse,exec -e'print +(split//,shift)[$_..$_]'
I won't show you the output, because I have one more tip. Just a few weeks ago, Stephen McCamant released a new backend module that blows Terse out of the water. It's called B::Concise, and while it's only been added to the standard distro for very recent bleadperls, you can download it from the APC. Once you've got it, stick it somewhere in your INC path under a `B' directory, and use it like so:
Or, to see the exec order:
As you can see from the above, the aelemfast (which accesses elements of the array in the glob *_) opcodes execute before the shift.