Applicative functors are less powerful than monads. monad-embed offers the full power of monads with a syntax as nice, if not nicer, than that of applicative functors.

This allows all sorts of neat things like using the `IO`

monad to `filter`

a list by asking the user about each item as we get to it, or using the `StateT`

monad transformer to count the number of comparisons needed to `quicksort`

a list.

Note that monad-embed and applicative functors are not mutually exclusive. If you want an applicative functor that isn't a monad, you can use `pure`

and `<*>`

just like you would in Haskell. monad-embed could even be combined with applicative idiom brackets. (I'm ignoring the fact that monad-embed doesn't support infix operators nor type classes, because they could be added.)

Another option would be to extend monad-embed to allow flavors to be either applicative functors or monads, and to only require that an expression's flavor be a monad if it contains strict `do`

-bindings or `do`

-actions. However, I haven't looked into this very much.

monad-embed orders side effects according to the following rules:

- In expressions of the form
`f a`

, the side effects of`f`

itself are performed first, followed by the side effects of`a`

, and then any side effects in the body of the function`f`

. - Expressions of the form
`a `f` b`

are desugared to`f a b`

. Note that this means that the side effects of`f`

are evaluated first, even though it appears after`a`

in the source code. - In expressions of the form
`do { a; } then b`

, the side effects of`a`

are evaluated before the side effects of`b`

. The same goes for expressions of the form`do { v = a; } then b`

.

These rules are, in a sense, arbitrary. If the first rule were reversed, so that `f a`

would perform the side effects of `a`

before the side effects of `f`

, then monad-embed would still be a consistent and usable language.

(In C, the ordering in which function arguments are evaluated is implementation-dependent. It is ironic that a functional language has a more clearly defined ordering of side effects than an imperative language.)

`flip f a b`

do and why?Evaluating `flip f a b`

would perform the following side effects:

- If
`f`

itself has any side effects, then they are performed first. Note that there is a difference between an expression having side effects and an expression refering to a function that has side effects when applied; only the side effects from the expression`f`

itself are performed here. - The side effects from
`a`

and`b`

are be performed, in that order. - Any side effects from calling
`f`

on`b`

are performed. - Any side effects from calling the return value of
`f b`

on`a`

are performed.

The reason why `f`

, `a`

, and `b`

are evaluated in that order is because `flip`

is a strict function which operates on a strict function and returns a strict function, so all of the arguments are evaluated strictly.

There is another `flip`

-like function in the standard library, called `zflip`

. The difference is that `flip`

operates on a strict function and returns a strict function, while `zflip`

operates on a lazy function and returns a lazy function:

flip :: (a :: *, b :: *, c :: *, m :: * -> *) => {m} (a -> b -> c) -> (b -> a -> c); zflip :: (a :: *, b :: *, c :: *, m :: * -> *) => {m} ([a] -> [b] -> c) -> ([b] -> [a] -> c);

Depending on the definition of `f'`

, evaluating `zflip f' [a] [b]`

might not perform the side effects of `a`

or `b`

at all, or it might perform them any number of times in any order. See this example program.

In general, you can work out how anything will behave by consulting the conversion rules.

Disciple allows functions to have side effects of modifying state or performing IO actions, but it does not express these actions via monads; the Disciple side effect system replaces the `ST`

and `IO`

monads.

monad-embed allows functions to have any side effect that can be expressed in a monad. The monad-embed side effect system is built on monads rather than replacing them. monad-embed code can be converted to Haskell code according to some simple rules; monad-embed is almost a syntactic sugar for Haskell.

Disciple allows destructive updates to any data structure; monad-embed does not.

In both Disciple and monad-embed, the type of a function restricts what side effects it can perform.

In both Disciple and monad-embed, functions are strict by default but can be made lazy if necessary. In Disciple, lazily evaluated code is not allowed to have side effects. In monad-embed, lazily evaluated code may have side effects; the side effects of a lazily evaluated chunk of code are evaluated every time the lazily evaluated value is used. (See this example program.)

(I'm not very familiar with Disciple; if I have made a mistake, please point it out.)