|P is for Practical|
Re: Turning foreach into map?by tlm (Prior)
|on Apr 05, 2005 at 00:19 UTC||Need Help??|
Once you start, you won't stop! You'll wonder how you could program without it.
As a first approximation, you can imagine map as being defined something like this:
This function my_map takes a code ref as its first argument, and returns the array consisting of applying that code ref to each one of the remaining arguments. Very useful! When programming we often want all the elements of some array, but transformed or operated on in some way. my_map (just like map) abstracts the essentials of this procedure, so that the only variables left are the actual input array and the operation that you want performed on each element.
You would use my_map like this:
or if you don't want to bother defining a sub just to feed it to my_map, you can give it a code ref written just for the ocassion:
Same thing. In fact, if you have arranged your definitions so that the compiler processes it before it processes the first call to it, you can toss the parens and write
which is beginning to resemble the way one uses Perl's map. Since this is such a handy thing to do, for its map Perl provides some "syntactic sugar" to simplify the writing of such expressions, so that for example you don't need to bother writing "sub" before the code ref. Also, in Perl's map, the code ref doesn't get its argument passed through its @_ array like is the case with my_map's $sub; instead map's the code ref picks up its argument from $_. In other words, if we wanted my_map to mimic Perl's map more closely, we could define it like this:
The only difference between this and the previous definition of my_map is in the first and second lines of the loop: 1) the loop variable is no longer $element, but $_; and 2) $sub is now called without arguments, since it will read its arguments from $_. Now we can write
and that's starting to look a lot like the standard
Now, watch this. If you defined a function that operated on $_, e.g.
you could just feed it to Perl's map as its first argument:
and you could also feed it to (the second version of) my_map
Notice that now the only difference that remains between the syntax of the two calls is that with my_map you need to explicitly take the reference to the sub you are passing as the first argument, hence the extra backslash. Can we get rid of this difference too? Yes, by using prototypes. I for one never use prototypes, so I'm not up on all their ins and outs, but for the sake of this illustration
(Note, aside from the prototype, there is no significant difference between this definition of my_map and the previous one; I just condensed it a little bit.) Now you can write,
OK, this last version of my_map does a limited impersonation of the "expression form" of map. A slight variant could be used to implement an impersonation of the "block form" of map; the only difference is in the prototype, but just to be clear, here it is in full:
With this final version of my_map you can write:
Note that even though we are using an anonymous code ref, the sub keyword is gone. This is syntactically identical to the "block form" of map.
Alas, my_map is not as versatile as map. It can't do some things that map can do, like this:
and it can't mimic both the "expression form" and the "block form" of map. But I think that by studying my_map you'll get a pretty good feel for what map is doing. That's the important thing; the other stuff with tweaking the definition of my_map so it's usage better resembles that of map is a bit of a distraction. The important thing is to understand that map takes a function as its first argument, and returns the array obtained from applying that function to the rest of its arguments.
OK, since I've made this far, I might as well tell you, if not the whole story, at least all that I know about map, and the only thing that's left is that both map and my_map have the potential to change their inputs. If, for example, you did this (using the last version of my_map):
...the input array @ints has been modified by my_map. Same thing with Perl's map, so watch out.
Last thing: you could play the same game with grep:
the lowliest monk