NEM: The fold function reduces a list (or other structure) to a single value by "folding" a binary operator between successive elements of the list. To illustrate, if you have a list containing numbers such as:

1 2 3 4 5

Then to sum that list you can fold a binary + operator between the elements, resulting in something like:

1 + 2 + 3 + 4 + 5

(assuming infix notation). This is essentially what a "fold" function does (sometimes called "reduce"). It takes a binary function, together with an initial value (to tack on to the end of the list) and a list:

You might wonder if we can perform the reverse operation, i.e., go from a value and a function that takes a single argument and produces a pair of results and from that generate a sequence/list. Well, you can indeed, and this is roughly equivalent to iterators. There is a demonstration of this unfold operation on that page.

escargo - This use of fold reminded me of something, and I couldn't remember what. Then I recalled: It reminds me of the APLreduce operator /, where

+/A

would add up all of the values of the vector A.

NEM - Yup, lots of languages have a similar function, and "reduce" is a common name for it, e.g. that is what it is called in Python (although, not for much longer [1]). Fold is a very powerful and general function [2] which captures a particular pattern of recursion (or iteration) over a container. Used with other higher-order functions like map, filter, and zip you can start doing some really powerful programming with a few statements (e.g., this [3] discussion of the Transfold Pattern).

You might still be wondering what the advantage of this over a traditional loop is. Well, basically, these higher-order functions capture a more specific usage pattern. This means that you can prove more interesting properties about them, but also you can optimise the heck out of them (not done here). For instance, people writing efficient containers can provide their own versions of fold etc which are especially optimised for traversing that particular container in an efficient manner. With more generic looping constructs you are not just specifying what you want to achieve, but also to some extent how to achieve it, which leaves very little room for optimisations. It is my belief that high-level scripting languages should be moving towards these higher-level container-oriented constructs where possible, as they offer conciseness and the possibility for speed. As shown above you can also define lots of other constructs very simply in terms of fold and chums, without adding much extra code at all. This means two things: firstly, if you optimise fold, then you get speed ups in all the other operations (same applies to e.g. foreach, but there are less opportunities); and, secondly, you can make fold a generic operation over different containers so that all a new container author has to do is provide a couple of generic higher-order functions and gets a whole bunch of functionality for free (e.g., sum, product etc over the new container). I think these are real wins of this type of programming, and indeed wins over list comprehensions which are often seen as a better replacement -- well they are, if all you use are lists.

RS on 2005-09-22 played with the above fold and rewrote it with func sugar like this (also, an {*}-less def for people not yet on 8.5):

NEM13 July 2006: Here's a simple implementation of a left-fold operation in C for speed. Copy + paste into a fold.c and then compile using the same instructions on Hello World as a C extension. Performance should be roughly on a par with foreach.