(This is explained in my article "foldl traverses with State, foldr traverses with anything": https://h2.jaguarpaw.co.uk/posts/foldl-traverses-state-foldr...)
go [] = ...
go head:remainder = ...
instead of hacking it together with a fold?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.
Most recursion is through fold and unfold
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.
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.
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.
It just gets confusing when you're dealing with lots of deferred/lazy operations.
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.
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.
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.
The compiler itself acts as a steering function for the AI. I've also had this experience with Rust.