After grabbing some water, I walked back and realized that @last_elements is (uh-oh) a transitory variable. (and wouldn'tcha know it, I try to look up on the web why transitory variables are bad, and I can't find anything. Dang; I'm sure dominus wrote about this somewhere. Or maybe this is hard water I'm drinking.) So, with a vague idea that some variables are "good" and others are "bad", I wanted to re-write my method to just return the list of @last_elements without actually storing into a list. (Sidenote: or is this foolish? Am I just inviting bogarts into my code?)

After a bit of toying, I realized that there are other ways to iterate over a list than by using for. Enter sort, map, and grep.

My questions:
1. What other ways are there to iterate over the list besides for, sort, map, and grep?
2. Why don't my slice_with_grep and slice_with_sort functions return what I'm expecting?
3. Am I drunk, or is the water? That is, have I invented this whole notion of a "transitory variable", or is it really something that exists (albeit momentarily) and should be avoided?

A transitory variable is a variable that isn't used for anything other than to schlep data from one line to another. (I'm not sure the term is right, but I think it's what you mean. I call 'em "useless variables", myself.) In other words, if I'm going to say:

Oops, on line 2 up there we changed the value of $foo. Also, it makes refactoring harder-- what if you wanted to pull out the stuff inside the if statement into its own subroutine? It'd be simpler if you didn't have $foo there at all, and just called get_foo() when you needed a foo-value.

In your code, @for_data, @map_data, @sort_data, and @grep_data are all transitory variables. Ironically, @last_elements is not... you're using it to collect elements! Nothing wrong with that.

As for why slce_with_sort() and slice_with_grep() aren't doing what you expect, it's because sort and grep don't do what you apparently think they do. :) The block argument to grep is a test block, not a filter block. So the statement

means, "If the item at index 2 of @$_ evaluates to true, return $_." The last bit is important-- it doesn't return the item at index 2, it returns the whole thing. A similar thing is happening with sort. You're sorting each row based on the value of the last column, and returning a list of the rows. Since the values are identical, it doesn't even change their order. :)

As I learn more about Perl and programming in general, I find myself re-reading articles and saying, "Ohhh.... so that's what it means...". Case in point: Coping with Scoping. Thanks for the pointer.

Dropping off to sleep last night I realized that the article I was thinking of was a Red Flags article on perl.com. The actual term mjd used was synthetic variables although in a different Red Flags article he talks about synthetic code

I'd like to read that again when it's updated to describe 'our'. I use 'our' all the time but the cross-over between the previously totally unrelated realms of lexical and package variables is still a bit vague in my mind.