> the first example explains a monad
Strictly speaking that's wrong. Yes, ZIO is a monadic type. But you really don't need to understand monads to understand the example. In fact, the word monad does not even appear at all. Or would you say javascript also "explains a monad" when someone explains how to map/flatmap over an array? I doubt it.
> That first example shows that the for syntax desugars to nested flatMap. Which is analogous to Haskell’s do notation, which desugars to nested bind.
> The abstractions you said are not there, seem to actually be there in zio!
Again, those concepts are even in javascript. In fact, they are in every language. The question is if it is decided to make them explicit and reusable or not. And ZIO chose to not require any knowledge of them to be able to use the library - and that's what we are talking about here no?
Let's look at the code of flatMap that you are complaining about:
/**
* Returns an effect that models the execution of this effect, followed by the
* passing of its value to the specified continuation function `k`, followed
* by the effect that it returns.
*
* {{{
* val parsed = readFile("foo.txt").flatMap(file => parseFile(file))
* }}}
*/
def flatMap[R1 <: R, E1 >: E, B](k: A => ZIO[R1, E1, B])(implicit trace: Trace): ZIO[R1, E1, B] =
ZIO.OnSuccess(trace, self, k)
Where are monads, monoids, functors, ... here? They are not to be found. Replace "flatMap" with "then" and you pretty much have javascript's promises.