fam-proposal | 易学教程

Why should Applicative be a superclass of Monad?

阅读更多关于 Why should Applicative be a superclass of Monad?

问题 Given: Applicative m, Monad m => mf :: m (a -> b), ma :: m a it seems to be considered a law that: mf <*> ma === do { f <- mf; a <- ma; return (f a) } or more concisely: (<*>) === ap The documentation for Control.Applicative says that <*> is "sequential application," and that suggests that (<*>) = ap . This means that <*> must evaluate effects sequentially from left to right, for consistency with >>= ... But that feels wrong. McBride and Paterson's original paper seems to imply that the left

Must I implement Applicative and Functor to implement a Monad

阅读更多关于 Must I implement Applicative and Functor to implement a Monad

问题 I'm trying to implement a Monad instance. As a simpler example, assume the following: data Maybee a = Notheeng | Juust a instance Monad Maybee where return x = Juust x Notheeng >>= f = Notheeng Juust x >>= f = f x fail _ = Notheeng This should be the standard implementation of Maybe as far as I know. However, this doesn't compile, because the compiler complains: No instance for (Applicative Maybee) and similarly he wants a Functor instance once the Applicative is given. So: Simple question:

Why should Applicative be a superclass of Monad?

阅读更多关于 Why should Applicative be a superclass of Monad?

Given: Applicative m, Monad m => mf :: m (a -> b), ma :: m a it seems to be considered a law that: mf <*> ma === do { f <- mf; a <- ma; return (f a) } or more concisely: (<*>) === ap The documentation for Control.Applicative says that <*> is "sequential application," and that suggests that (<*>) = ap . This means that <*> must evaluate effects sequentially from left to right, for consistency with >>= ... But that feels wrong. McBride and Paterson's original paper seems to imply that the left-to-right sequencing is arbitrary: The IO monad, and indeed any Monad, can be made Applicative by taking