[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