Ertugrul Söylemez wrote:
> > Could someone outline for me the downsides of using the Prompt monad?
>
> For one thing I find its definition to be overcomplicated for what it
> does.

I'm assuming that this is referring to the MonadPrompt package...
If you mean the type, it's essentially the same as

    http://hackage.haskell.org/package/free-4.12.4/docs/src/Control-Monad-Free-Church.html#F

after plugging in PromptF' p (see below). The point is to make left
associative use of >=> efficient.

> For another the same can be achieved with free monads in a more
> transparent and flexible manner:
>
>     import Control.Monad.Free.Class
>
>     data PromptF a b x = PromptF (b -> x) a
>         deriving (Functor)

More accurately,

    data PromptF' p x = forall a. PromptF (a -> x) (p a)

(with the obvious Functor instance).

The existential highlights an important design idea of the Prompt monad,
namely that a monadic DSL would be specified by a GADT (p a), where `a`
represents the result type of the corresponding operation. So, for a
state monad, one would use

    data PromptState s a where
        Get :: PromptState s s
        Put :: s -> PromptState s ()

which defines a "get" operation without arguments that returns a value
of type s, and a "put" operation that takes a value of type s, but
returns nothing.

This is slightly less expressive than free monads (the main loss, I
believe, is that a prompt GADT cannot express that an operation is
necessarily a leaf of computations; while free monads can also express
non-determinism, that does not give rise to any useful guarantees for
the resulting behavior, as far as I can see). I would argue that prompt
GADTs are sufficient for many applications, and that thinking in terms
of interfaces is more natural to many programmers than thinking in terms
of unfolding computations.