Proposal: Move `mapM` and `sequence` out of Traversable
Georgi Lyubenov
godzbanebane at gmail.com
Sat Nov 7 20:29:09 UTC 2020
Hi!
Regarding the "there can be no instance for which mapM is more efficient
than traverse":
There have been issues with Applicative functions leaking memory where
Monad ones aren't in Polysemy - some of these have been fixed, but it's not
clear that there are none left.
There is also this claim in parser-combinators
<https://hackage.haskell.org/package/parser-combinators-1.2.1/docs/Control-Applicative-Combinators.html>
:
> Due to the nature of the Applicative
<https://hackage.haskell.org/package/base-4.12.0.0/docs/Control-Applicative.html#t:Applicative>
and Alternative
<https://hackage.haskell.org/package/base-4.12.0.0/docs/Control-Applicative.html#t:Alternative>
abstractions, they are prone to memory leaks and not as efficient as their
monadic counterparts. Although all the combinators we provide in this
module are perfectly expressible in terms of Applicative
<https://hackage.haskell.org/package/base-4.12.0.0/docs/Control-Applicative.html#t:Applicative>
and Alternative
<https://hackage.haskell.org/package/base-4.12.0.0/docs/Control-Applicative.html#t:Alternative>,
please prefer Control.Monad.Combinators
<https://hackage.haskell.org/package/parser-combinators-1.2.1/docs/Control-Monad-Combinators.html>
instead when possible.
I have not verified it, but it is a bit worrying.
Personally I would love to know of some kind of reasoning regarding these
things, as I'm not aware of any! (efficiency of Applicative vs Monad based
functions)
======
Georgi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20201107/db4aaeac/attachment.html>
More information about the Libraries
mailing list