The author's definition of foldr is wrong, which makes the post pretty much impossible to understand if you don't already know what it's trying to say.
The correct definition, in the author's style, is
foldr :: (a -> b -> b) -> b -> [a] -> b
foldr f = go
where
go z (x:xs) = f x (go z xs)
go z [] = z
It's better written with the cases for go reversed, so the base case comes first, or without the helper function at all, as
foldr :: (a -> b -> b) -> b -> [a] -> b
foldr f z [] = z
foldr f z (x:xs) = f x (foldr z xs)
But I suppose that if you're reading this then you already knew that. I'm really writing because I noticed that this submission, like another submission that made the front page of HN twice in the past two days [0], touches on the same material as Ch. 6 of Richard Bird and Philip Wadler's book Introduction to Functional Programming [1], which I happened to be re-reading a couple of nights ago. And I want to tell you to go read it.
Really, if you find this sort of thing interesting, you should read it. The book isn't strictly a Haskell book—it was published in 1988, just as Haskell's designers (the book's authors among them) were getting going. But their book remains one of the best, most timeless introductions to programming in a lazy functional language. It's written in a sort of functional pseudo-code (which Haskell aspires to be) and captures all of the excitement and optimism of the coming of age of functional programming in the years after Miranda.
Bird and Wadler's book is quite different from standard contemporary recommendations like Learn You a Haskell for Great Good; it's more like an extended version of John Hughes's famous paper Why Functional Programming Matters [2], which is to say that it makes the case for functional programming over imperative programming and illustrates the strengths of lazy evaluation. The book continues on from the basics to discuss evaluation strategies, efficiency, and other practical mid-level topics in some depth, without breaking stride; it doesn't touch much of the algebraic or categorical underpinnings of Haskell, which is the relative strength of an introduction like Learn You. That makes the two together a great one-two punch for learning Haskell.
I've not read Bird's new book, but the table of contents suggests it's a more modern but more basic introduction to pure functional programming. The new book covers monadic IO and monadic parsing, for example, but doesn't discuss the space and time efficiency of lazy versus strict evaluation.
I really like the oldies because they seem to express the joyful, revelatory aspects of functional programming better; more modern texts tend, in my opinion, to get bogged down in the mundane realities and masochism before properly motivating their audience. The first great truth of Haskell is that imperative programming is unsatisfactory, and if you haven't realized that yet, you're not ready to move on.
If you don't want to commit to Bird and Wadler's text, at least try Hughes's excellent paper (linked in my grandfather post); if that turns you on, you'll want to read the book.
The correct definition, in the author's style, is
It's better written with the cases for go reversed, so the base case comes first, or without the helper function at all, as But I suppose that if you're reading this then you already knew that. I'm really writing because I noticed that this submission, like another submission that made the front page of HN twice in the past two days [0], touches on the same material as Ch. 6 of Richard Bird and Philip Wadler's book Introduction to Functional Programming [1], which I happened to be re-reading a couple of nights ago. And I want to tell you to go read it.Really, if you find this sort of thing interesting, you should read it. The book isn't strictly a Haskell book—it was published in 1988, just as Haskell's designers (the book's authors among them) were getting going. But their book remains one of the best, most timeless introductions to programming in a lazy functional language. It's written in a sort of functional pseudo-code (which Haskell aspires to be) and captures all of the excitement and optimism of the coming of age of functional programming in the years after Miranda.
Bird and Wadler's book is quite different from standard contemporary recommendations like Learn You a Haskell for Great Good; it's more like an extended version of John Hughes's famous paper Why Functional Programming Matters [2], which is to say that it makes the case for functional programming over imperative programming and illustrates the strengths of lazy evaluation. The book continues on from the basics to discuss evaluation strategies, efficiency, and other practical mid-level topics in some depth, without breaking stride; it doesn't touch much of the algebraic or categorical underpinnings of Haskell, which is the relative strength of an introduction like Learn You. That makes the two together a great one-two punch for learning Haskell.
0. https://news.ycombinator.com/item?id=8645292
1. http://www.nlda-tw.nl/janmartin/vakken/TFIT/Extra%20materiaa... [PDF]
2. http://worrydream.com/refs/Hughes-WhyFunctionalProgrammingMa... [PDF]