[Haskell-cafe] Downsides of the Prompt Monad

[Bertram Felgenhauer]

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.

Cheers,

Bertram

P.S. it may be worth noting that MonadPrompt predates the advent of free
monads in the Haskell community.