Well, I think it depends on the person who you're trying to teach. I, for one, spent nearly two years before I even started learning Haskell, precisely because I can't bear the thought of using constructs I don't understand. In this two years time I learned OCaml, Scheme and Erlang, not to mention read countless implementations of monads in these and other languages, just so I could start learning Haskell.
As a side effect (haha) I realized that a) a monad is very interesting and useful concept, no matter in which language; b) Haskell "cheats" heavily in order to be able to do I/O (and side effects) and c) it's this cheating (ie. IO part of IO Monad) which makes it hard to understand (I really prefer Clean's approach, where you get explicit 'world' object to manipulate). As a result I don't know when or even if I'll learn Haskell - and it's caused solely by the lack of full, up-front explanation of Haskell I/O model in most (all?) learning materials for the language.
So, for me, yes - you need to teach me "theoretical grounding of monads" and more or you'll lose me. I never read Zed's books, but I think he's targeting people like me, so your criticism is invalid.
And yet Zed seems to think he can teach the basis by which Ruby's for ... in works without laying nearly the same amount of groundwork. That's the real question---why do you need to go over so much in so much detail in the one case, but somehow the other is significantly simpler? (Especially if the second is actually syntactic sugar for the first!)
"As a result I don't know when or even if I'll learn Haskell - and it's caused solely by the lack of full, up-front explanation of Haskell I/O model in most (all?) learning materials for the language."
The IO monad is just like the State monad, except you can't get the State back out. You're passing around RealWorld. (In any event the "theoretical grounding of monads" doesn't tell you anything about IO. It would tell you things about monads in general---monadic bind and return and join, etc. Haskell may be doing weird things with its IO monad, but your objection actually bypasses what I was talking about, which is the category theory shee that Haskell is known for, but is also found in, say, Scala, where IO is not done through a special monad.)
ETA: given that these books are apparently for people who might need to be taught about variables in the first place, I wonder how accurate your conception of how like you they are is, and how much that resemblance applies to the case at hand. To reiterate, I can't really understand why any explanation that would pass muster with Zed for adequately explaining how "for foo in bar" works in Ruby, including the binding of the name foo, the repeated execution of the body, etc., couldn't be straightforwardly adapted to "bar.each { |foo| ... }". Would the adaptation not get into the weeds of the .each method? Indeed it would not. But then, the explanation of "for ... each" also didn't get into the weeds of that. Both should be acceptable if either is.
As a side effect (haha) I realized that a) a monad is very interesting and useful concept, no matter in which language; b) Haskell "cheats" heavily in order to be able to do I/O (and side effects) and c) it's this cheating (ie. IO part of IO Monad) which makes it hard to understand (I really prefer Clean's approach, where you get explicit 'world' object to manipulate). As a result I don't know when or even if I'll learn Haskell - and it's caused solely by the lack of full, up-front explanation of Haskell I/O model in most (all?) learning materials for the language.
So, for me, yes - you need to teach me "theoretical grounding of monads" and more or you'll lose me. I never read Zed's books, but I think he's targeting people like me, so your criticism is invalid.