[Haskell-cafe] Downsides of the Prompt Monad

[Bertram Felgenhauer]

Ertugrul Söylemez wrote:
> >> 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).
> 
> Are we talking about the same PromptT here?  I was assuming this one:
> <https://hackage.haskell.org/package/prompt-0.1.1.2/docs/Control-Monad-Prompt.html#t:PromptT>.

I've looked a bit more closely at the difference between the prompt and
MonadPrompt packages. PromptT a b t r from the prompt package is a
newtype for

    forall m. Monad m => (a -> m (t b)) -> m (t r)

using the "universal" Cont/Codensity monad, this becomes

    forall x. (a -> (t b -> x) -> x) -> (t r -> x) -> x)

which is quite similar to the Prompt type from MonadPrompt:

    forall x. (p a -> (a -> x) -> x) -> (r -> x) -> x)

The main innovation in prompt seems to be the 't' argument, which
according to the package's readme, can be used for short-circuiting
evaluation and nondeterminism (branching computations). As I explained
in my previous email, the 'p' argument in MonadPrompt is meant to
describe the API of a monadic DSL. It appears that the two ideas could
be combined in a single type,

   forall x. (p a -> (t a -> x) -> x) -> (t r -> x) -> x)

or

   forall m. Monad m => (p a -> m (t a)) -> m (t r)

or, using the free monad defined by the functor

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

Perhaps this is worth investigating further.

Cheers,

Bertram