haskell - Is Applicative IO implemented based on functions from Monad IO? -

in "learn haskell great good!" author claims applicative io instance implemented this:

instance applicative io     pure = return     <*> b =         f <-         x <- b         return (f x) 

i might wrong, seems both return, , do-specific constructs (some sugared binds (>>=) ) comes monad io. assuming that's correct, actual question is:

why applicative io implementation depends on monad io functions/combinators?

isn't applicative less powerfull concept monad?

---

edit (some clarifications):

this implementation against intuition, because according typeclassopedia article it's required given type applicative before can made monad (or should in theory).

(...) according typeclassopedia article it's required given type applicative before can made monad (or should in theory).

yes, parenthetical aside issue here. in theory, monad should applicative, not required, historical reasons (i.e., because monad has been around longer). not peculiarity of monad, either.

consider actual definitions of relevant type classes, taken base package's source on hackage.

here's applicative:

class functor f => applicative f     pure  :: -> f     (<*>) :: f (a -> b) -> f -> f b     (*>)  :: f -> f b -> f b     (<*)  :: f -> f b -> f 

...about can observe following:

• the context correct given existing type classes, i.e., requires functor.
• it's defined in terms of function application, rather in (possibly more natural mathematical standpoint) terms of lifting tuples.
• it includes technically superfluous operators equivalent lifting constant functions.

meanwhile, here's monad:

class monad m     (>>=)       :: m -> (a -> m b) -> m b     (>>)        :: m -> m b -> m b     return      :: -> m     fail        :: string -> m 

...about can observe following:

• the context not ignores applicative, functor, both of logically implied monad not explicitly required.
• it's defined in terms of function application, rather more mathematically natural definition using return , join.
• it includes technically superfluous operator equivalent lifting constant function.
• it includes fail doesn't fit in @ all.

in general, ways monad type class differs mathematical concept it's based on can traced through history abstraction programming. some, function application bias shares applicative, reflection of existing in functional language; others, fail or lack of appropriate class context, historical accidents more else.

what comes down having instance of monad implies instance applicative, in turn implies instance functor. class context merely formalizes explicitly; remains true regardless. stands, given monad instance, both functor , applicative can defined in generic way. applicative "less powerful" monad in same sense more general: monad automatically applicative if copy+paste generalized instance, there exist applicative instances cannot defined monad.

a class context, functor f => applicative f says 2 things: latter implies former, , definition must exist fulfill implication. in many cases, defining latter implicitly defines former anyway, compiler cannot deduce in general, , requires both instances written out explicitly. same thing can observed eq , ord--the latter implies former, still need define eq instance in order define 1 ord.