That was exactly my point about the foldr example: in real-world code, you may need a function that perfectly matches foldr's type signature. But following the author's methodology, you'll write out a new implementation of foldr, when what you should actually be doing is calling foldr in that type hole.

This ties back in to my comment about code review. Think about how a patch from someone who applied the author's method would look like: it would contain a lot of in-place implementations that they sort of stumbled into, when in fact they should have reused well-known functions. Someone should then try to review that code to see if some implementation is not actually a well-known function.

Even ghc suggested at some point that he should use maxBound or minBound instead of writing his own thing.

Edit: I should also add that there is no reason to think that foldr is the right implementation of zoop without more context. For example, zoop could be a function just like foldr but that works on the reversed list of `as`. Or one that skips every second element of `as`. If we're just guessing based on type, and don't know what the code is supposed to do, it's easy to mess up.