[doyougnu]

A chapter dedicated to understanding laziness is indeed doable, but my target audience is Haskellers that have already read through LYAH, Real-World Haskell and perhaps UPenn's CIS 194 class; each of which cover laziness and so I want to focus on things that should be more widely used or known, such as info table profiling, eventlog or the one-shot monad trick.

But that doesn't mean that laziness doesn't come up! For example, its impossible to demonstrate using (or defining) unboxed or unlifted types without discussing laziness. The same goes for using GHC.Exts and explaining the difference between Data.Map and Data.Map.Strict.

[chowells]

Those books define laziness, and provide a couple examples - but they do not teach a programmer how to use it correctly.

Correct use of laziness involves choosing sufficient space invariants, implementing them, and documenting them. This is critical for writing efficient code in Haskell, and rejecting the "everything strict" cargo cult at the same time allows you to recover compositionality.

There was a period of time around 15 years ago, back before core libraries really started to understand this concept, and they would often have updates that silently made things too strict, breaking my code that was using their previous laziness in ways they hadn't predicted.

And it bugs me when I see new resources being set up to train people to write code that prevents my creative uses of their libraries. We should teach people how to write efficient Haskell code that's still Haskell code. It's great that we have so many advanced strictness tools when they're needed. But they shouldn't be reached for before we know if they help.

[doyougnu]

Great! If you could open an issue and perhaps lay out what you would like to see I would be more than happy to add a chapter like this. This book should serve the community and I think you've described a good gap that the book has which we could close with such a chapter.