A neat fact about foldr on lists, unlike foldl, is that it actually passes control flow entirely to the accumulating function on each fold step. That means you can use foldr to implement arbitrary traversals of lists, including foldl' or list traversals that exit early. See https://github.com/quchen/articles/blob/master/useful_techni...

Yes, because foldr is equivalent to for_, that is, iterating over a container and performing an effectful action (what in other languages would be called "doing something") for each element. Uses of foldr can always be rewritten to uses of for_, and I find things much clearer in terms of for_!

(This is explained in my article "foldl traverses with State, foldr traverses with anything": https://h2.jaguarpaw.co.uk/posts/foldl-traverses-state-foldr...)

At some point doesn't it become easier to write the function explicitly? As in

    go [] = ...
    go head:remainder = ...

instead of hacking it together with a fold?

If you don’t already know about folds, arguably yes.

If you do, then a quick glance at whether you’re using foldl’ or foldr tells you about what the function is allowed to do, which cuts down a little on comprehension.

List traversals are typically compact enough that there’s not a huge difference either way.

One advantage of using a fold, even in these cases, is that newcomers to Haskell often get so carried away with (and confused by) the power of pattern matching that they’ll write bizarre overly-complicated list traversals by hand, when a simpler mechanism exists that they just haven’t yet internalized.

There's a relatively popular point of view amongst Haskell programmers that explicit recursion is the goto of functional programming; a dedicated folding or traversing function provides more clarity on what exactly the function intends to do. The extreme end of this is recursion schemes and memes like zygohistomorphic prepomorphisms, which are almost certainly overkill on lists proper but might be useful when traversing bigger recursive structures. Personally, I almost always prefer to find a monoid to map the list elements into, and use `fold :: (Monoid m, Foldable t) => t m -> m`. It's essentially the equivalent of using `sum()` instead of `reduce()` in python

Every time I spend a lot of thought on a problem I always go back to F-Algebras and F-CoAlgebras.

Most recursion is through fold and unfold

Folding 'fold' into contortions to use it as a generic List iterator does not "provide clarity".

In functional programming, there is no "generic list iterator", though. It matters what the output is, whether you need to look at the value of previous iterations, etc.

One of the links (on Fusion) points out that GHC in particular has a lot of optimizations and rewrite rules for folds and many Prelude functions written as simple recursion also include optimized fold representations to suggest to various stages of GHC's optimizer.

As with so many such topics it seems an interesting spectrum between clarity and/or aesthetics and potential performance optimizations. Especially because it often seems like one of those "learning curve flips the clarity/aesthetics preferences" because at some point of familiarity folds can be faster to read than trying to reason through an explicitly written recursion.

I think once you become comfortable with a fold, and of thinking in that manner, it actually becomes easier with a fold.

Or just use `for_` instead of explicit recursion ...

> Both foldl and foldr traverse the structure in the same order, which in the case of lists means left to right.

This characterization is debatable, unless one is assuming single-linked lists, which by definition can only be traversed from left to right (even moreso in a lazy language where the list may have indefinite length). When implemented in a strict language on an array or a double-linked list, the traversal order will be right-to-left for foldr.

A more accurate statement would be that in Haskell, lists can only be traversed from left to right, and therefore the implementations of both foldl and foldr in Haskell are necessarily based on that.

Right. The article is only talking about the foldr and foldl functions on Haskell lists. In the addendum it talks about the functions on other data structures (presumably the implementation of instances of the Foldable class). It would be more instructive to examine the definitions of foldr and foldl on other types such as Map instead of yet another custom list type.

I actually think examining the definitions of folds in Map (a binary tree) is perhaps pedagogically a better starting point. The singly linked list is inherently left biased. A binary tree is symmetrical. So the implementation of foldr and foldl on a binary tree is more similar: literally flipping the order of the arguments to the accumulation function and swapping the left and right children. Furthermore you can induce the “early termination” by laziness behavior by adjusting whether your accumulation function forces the first or second argument. And all four versions foldr, foldl, foldr' and foldl' are meaningful.

A list in Haskell is a singly-linked list with the possibility of tail sharing.

To a CS person, "ordering" is about the arrangement of a list. But pretty much everyone else will think about a *temporal* order of operations. And in that case it is indeed "starting" from the right or left.

It just gets confusing when you're dealing with lots of deferred/lazy operations.

I noticed that AI likes to overuse foldl' and foldr (especially foldr) including analogous versions on Maps, even when there are simpler and more straightforward ways to achieve the same thing.

When AI writes foldr with a complicated accumulation function, I’d prompt AI to define a custom monoidal structure and then use foldMap. Then the reader doesn’t have to think about the asymmetric accumulation function and instead think about the mapping operation and the associative combine function separately. Factoring out the two jobs of the accumulation function is a great trick to improve readability: excellent tradeoff if the human is mostly reading the code.

The advantage of Haskell is higher quality code with fewer bugs even when you write fewer unit tests. The advantage is the same whether humans write the code or AI writes it.

This might not be noticeable if you only write short programs: if the human can put the entire program in the head or if the AI can keep the whole thing in the context window. It matters much more when the program gets bigger.

Can you produce those studies? Genuinely interested. Intuitively, I would have thought properly used Haskell prevents a lot of bugs by virtue if its type system, which allows for encoding internal constraints to a certain degree.

The extreme end of this is dependent types, which is so strong that it can be used as a foundation for mathematics itself, and is the principle that the Lean, the proof assistance, is used on. A Lean "program" is effectively proven to be bug-free.

In my experience, AI does really well with a good type system. It tries something, if it doesn't compile, looks at the message, fixes, etc etc.

The compiler itself acts as a steering function for the AI. I've also had this experience with Rust.

my haskell is still natty

This was a very interesting read. Makes me want to try learning Haskell again after failing miserably a few years ago

Main takeaway: foldl can be tail recursive.

How about Hodl?

Cost can be much greater than either foldl or foldr

What I learned, many years ago, is that foldr was a footgun, and that foldl1' was almost certainly what I wanted.

Don't you mean foldl (non-strict version) is a footgun? I can't think of how foldr is a footgun, at least not in a lazy language.