As to how to traverse a tree or other nonlinear structure, there are two answers. The first is that the Functor instance decides on the order. The other is that it usually doesn’t matter, due to purity. If the traversal has no side effects, the order of evaluation doesn’t matter. Whole parts of it (up to and including the entire traversal) may in fact never be executed, or may be optimized away.

And so, the standard instance of Functor for a binary tree like mine is:
instance Functor Tree where
fmap _ Empty = Empty
fmap f (Node a l r) = Node (f a) (fmap f l) (fmap f r)
which appears a priori to implement a preorder traversal. On a second look, though, since Haskell is non-strict, no particular order is guaranteed. However, the order is guaranteed to be fixed, since purity means it will have the same result every time you call it.

It can’t. Try-every-path exhaustive searches are described using the list monad. As an example, finding Pythagorean triples with a given perimeter.

triples n = [ (a,b, c) | a <- [1..n], b <- [1..a], let c = n – a – b, a^2 + b^2 == c^2 ]

This is a list comprehension, which is syntactic sugar for the list monad.

In the case of an alpha-beta AI, I now know that you can’t quite use a list comprehension, as they model an exhaustive search. One that short-circuits certain paths when they become too unfavourable can be defined using a similar monad, though obviously the syntax won’t be as short as list comprehensions, since you also need to specify the cutoff for an unfavourable result, a possible short-circuiting if the best possible value has already been seen, etc. The code here gives a working alpha-beta and short-circuiting model.

I’m well-aware that Perl, Python and similar have a fully general map (and filter/grep and fold/reduce/etc) function. Even more so, Perl has full-strength lexical closures. It’s pretty close to an acceptable functional language (indeed, see Higher Order Perl). Unfortunately the function call overhead (due mostly to list-flattening) makes it rather a slow one. (Does Python have closures (not just lambdas)? I don’t know it as well as I do Perl. Ruby?)

@ pozorvlak:
Any loop, or equivalently, any linear recursion, can be written using foldr. Since, as I say, the various standard HOFs cover most linear recursion patterns, see these redefinitions in terms of foldr:

map f = foldr (\x xs -> f x : xs ) []
filter f = foldr (\x xs -> if p x then x:xs else xs) []
length = foldr (\_ n -> n+1) 0

@ Rick:

I’m not mainly concerned with performance, though of course an optimizing compiler such as GHC has to work a lot less hard to know what map means than to analyze a custom linear recursion, and so is more likely to optimize a map, and more effective at doing so.

I feel that the crux of the article was in fact code readability, both in the eye of the programmer and the reader. I came from an imperative background too, and so as I said in the main article, I found it hard to reason in terms of higher-order functions when I first came to Haskell. When I was reading someone else’s code, I always had to pause and think about what foldr or map meant. Now that I’ve become more accustomed to Haskell, I don’t hesitate anymore: they are perfectly natural.

If this seems to demand more of the programmer than explicit recursion, I understand the point. But to someone who doesn’t know English very well, reading this comment would be difficult. To a fluent speaker, its meaning is plain. I used several English idioms (crux of the article, accustomed to something, to see a point), and while I could have written them more explicitly, it would come at the cost of making the post harder to read for one fluent in English. So I believe it to be with the use of higher-order functions compared to explicit recursion. If someone writes a map explicitly, the reader needs to double-check that the stop condition is the same, that the recursion pattern really is that of map. “map” guarantees all of those things.

This is an interesting point. I can appreciate the code minimization benefits of this approach, but it seems like you are implying (without saying it) that there are some performance reasons why higher order functions are better choices than explicit recursions.

If this is true (and correct me if I misunderstood), I’d be interested to know a little more about this. Are there any references that talk about this from a performance perspective ? This is the first time I’ve come across the idea of higher order functions out performing explicit recursions.

I come from a java-shop background, and one of the things stressed there is code-readability. I’ve always found that mentally digesting folds in someone else is code is tricky compared with explicit recursions (especially for newbies like you said),
so if there wasn’t a performance benefit in writing recursions with folds, wouldn’t the readability trump the code minimization ?

Interested to hear your comments. Thanks,

Rick