Maps, folds, and degrees of freedom
Python 3000 will remove maps and folds. (Python names: map & reduce). I believe this is a mistake.
Fold and map state the nature of the data-dependencies in a segment of code: the way data flows through that code. It is the fact that they limit the data-dependencies that is useful. When I see reduce(lambda x,y: x|y, ss, set()) I know that the sets will all be ored together. When I read a for loop doing the same thing I have to be much more careful, as a for loop does not limit the way in which data flows though it: it has a much higher data-dependency degree of freedom.
Examples don’t really capture this, because it has more to do with the mind of the beholder than the actual mechanics. Nevertheless the difference is real, and has real implications for distributing processing, as this paper from google shows. (via joel).
Indeed the use of maps and folds in Python is limited by other factors. I use maps and folds much more in Haskell, because Haskell efficiently supports functional composition:
f . g = lambda x: f(g(x))
map f . foldl [] g . map h . fold ...
August 3rd, 2006 at 4:32 pm
It’s only removing them as builtins. They will still be available, and of course you can implement them easily enough. Something like mapreduce isn’t the builtin map(), it’s quite another implementation that is different enough from the builtin that you couldn’t replace the builtin with it.
Heck, you could probably transform generator expressions into a distributed map if you wanted to. “map” is just language and idiom, it shouldn’t be confused as being any more than that.
August 3rd, 2006 at 5:38 pm
I agree they can be written in python, although they may be slower when byte interpreted. The point I was making was more about why they are useful.