[Haskell-cafe] Downsides of the Prompt Monad

Bertram Felgenhauer bertram.felgenhauer at googlemail.com
Fri Apr 7 16:03:07 UTC 2017


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>.

No, I'm talking about

    https://hackage.haskell.org/package/MonadPrompt-1.0.0.5/docs/src/Control-Monad-Prompt.html#Prompt

(FWIW, I did mention the package name in my mail.)

The type in the prompt package does not seem to offer the main benefit
I mentioned, namely that the prompt value encodes the type of the return
value of the `prompt` action; indeed, `prompt` in the prompt package has
type

  prompt :: MonadPrompt a b m => a -> m b

in contrast to

  prompt :: MonadPrompt p m => p a -> m a

in MonadPrompt.

> Even if not, it seems to me that it should be an abstraction layer above
> free monads.  It could be a very thin layer around F/FT.  That would
> facilitate reuse.

MonadPrompt is a very thin standalone package... I would be quite sad to
lose that property.

Cheers,

Bertram


More information about the Haskell-Cafe mailing list