[Haskell-cafe] Downsides of the Prompt Monad

David Menendez dave at zednenem.com
Fri Apr 7 04:28:24 UTC 2017

On Thu, Apr 6, 2017 at 1:53 PM, Bertram Felgenhauer via Haskell-Cafe <
haskell-cafe at haskell.org> wrote:

> 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.
It’s worth noting that Prompt p is the free monad for a type constructor p,
just as Free f is the free monad for a Functor f. As such, when p is a
Functor, they are isomorphic.

data Free f a = Var a | Wrap (f (Free f a))

newtype Prompt p a = Prompt { unPrompt :: forall b. (forall i. p i -> (i ->
b) -> b) -> (a -> b) -> b }
-- equivalently, Prompt p a = Done a | forall i. Prompt (p i) (i -> Prompt
p a)

prompt :: p a -> Prompt p a
prompt p = Prompt $ \c -> c p

promptFree :: Free f a -> Prompt f a
promptFree (Var a) = return a
promptFree (Wrap f) = prompt f >>= promptFree

freePrompt :: Functor f => Prompt f a -> Free f a
freePrompt m = unPrompt m (\f k -> Wrap (fmap k f)) Var

Thus, it’s entirely possible to do non-determinism and halting with Prompt.

Just to have a concrete example, here’s an interface that prints strings
and has non-determinism.

data W a where
    Print :: String -> W ()
    End :: W a
    Choose :: a -> a -> W a

Note that End and Choose are fully polymorphic. This means that an
interpreter has to pass one of the two provided values to the continuation
when it receives Choose, and it can’t call the continuation when it
receives End.

Dave Menendez <dave at zednenem.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20170407/9af57e12/attachment.html>

More information about the Haskell-Cafe mailing list