I don't see how it's tackling the 'where' block--or it that would even be possible under this scheme. I find that my code is much more legible with the houseke

I don't see how it's tackling the 'where' block--or it that would even be possible under this scheme. I find that my code is much more legible with the housekeeping and other less important helper-functions defined after the important bits. The clunky code that the author complains about can be much improved using where clauses to break it into chunks. Taking the authors example and moving some of the processing to a where clause makes the flow much easier to follow: someFunction conn (Foo n) (K {x=zot}) plib = do withTransaction conn $ \db -> coconut <- sizzleQuery [Foob n] potato <- sizzleQuery [Foob n] let sizzle = (zotify coconut) ++ potato ++ gravy record = fasterize $ makeRecord' sizzle date = dateOrError sizzle in catch handler $ insertIntoDB sizzle plib where sizzleQuery = queryTheDB "select * from sausages where sizzle = ?" zotify c = zot (plib $ zip [1..] c) dateOrError d = error "Unable to parse date" `fromMaybe` parseDate d "date" handler e = do something `with` (k $ the exception) makeRecord' s = (MakeRecord { recName = sizzle "name" , recAge = sizzle "age" , recDate = date }) $ Plib </> (fromMaybe "" $ sausages >>= bacon) Also one of my favorite features of Haskell is using the $ as an unmatched left parenthesis, saving you from that blob of closing parenthesis that every lisp expression accumulates. One last thing, the author complains about the ambiguity of the indentation, but doesn't make any comment about the brace & semi-colon syntax. I personally don't like it, but it should be explained why it isn't an acceptable solution.