<div dir="auto"><div dir="auto">Off the top of my head, I can't think of anything about sequence or sequenceA to justify their existence as class methods from the standpoint of practical programming. I could imagine they might be helpful to beginners who may find it easier to think about a container full of actions than about a container full of elements and a function that can be applied to them to get actions. But it's also not clear to me that removing methods is very valuable unless either:<br></div><div dir="auto"><br></div><div dir="auto">1. We get down to just one method, which can be good for performance with non-regular types, or</div><div dir="auto"><br></div><div dir="auto">2. We end up with a class that works with GND/DerivingVia, such as</div><div dir="auto"><br></div><div dir="auto"> class (Foldable t, Functor t) => Traversable t where</div><div dir="auto"> mapTraverse :: Applicative f => (t b -> r) -> (a -> f b) -> t a -> f r</div><div dir="auto"><br></div><div dir="auto">The one-method bonus can generally be worked around with auxiliary classes in the rare cases where it comes up, so I wouldn't worry about that too much here.</div><div dir="auto"></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Nov 7, 2020, 9:47 PM Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com">carter.schonwald@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">Yeah, mapM is semantically different from traverse. So dropping mapm seems ill advised. </div><div dir="auto"><br></div><div dir="auto">@david: is there an analogue for sequence?</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Nov 7, 2020 at 5:15 PM David Feuer <<a href="mailto:david.feuer@gmail.com" target="_blank" rel="noreferrer">david.feuer@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div dir="auto">In light of this example, I oppose the proposal.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Nov 7, 2020, 5:04 PM David Feuer <<a href="mailto:david.feuer@gmail.com" target="_blank" rel="noreferrer">david.feuer@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div dir="auto">I don't know about measurements or anything. There are certainly *implementation strategies* for mapM that don't translate well to traverse. Imagine a queue, for example. One way to write mapM is this:<div dir="auto"><br></div><div dir="auto">mapM f = go empty</div><div dir="auto"> where</div><div dir="auto"> go !acc xs = case uncons xs of</div><div dir="auto"> Just (x, xs') -> do</div><div dir="auto"> y <- f x</div><div dir="auto"> go (acc `snoc` y)</div><div dir="auto"> Nothing -> pure acc</div><div dir="auto"><br></div><div dir="auto">There's no way to do anything operationally equivalent with just Applicative.</div><div dir="auto"><br></div><div dir="auto">Is this a good way to write it? Well, that presumably depends on the queue and on the Monad, but I'd give it a good "possibly".</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Nov 7, 2020, 3:42 PM A S <<a href="mailto:masaeedu@gmail.com" rel="noreferrer noreferrer" target="_blank">masaeedu@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div dir="ltr"><div>> 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)<br><br></div>I agree. I'd be very interested in seeing an example (contrived or otherwise) of a specific Monad which is necessarily more efficient to `mapM` over some arbitrarily selected Traversable container than to `traverse`. That would be a good first step I think.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Nov 7, 2020 at 3:29 PM Georgi Lyubenov <<a href="mailto:godzbanebane@gmail.com" rel="noreferrer noreferrer noreferrer" target="_blank">godzbanebane@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div dir="ltr">Hi!<br><br>Regarding the "there can be no instance for which mapM is more efficient than traverse":<br>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.<br>There is also this claim in <a href="https://hackage.haskell.org/package/parser-combinators-1.2.1/docs/Control-Applicative-Combinators.html" rel="noreferrer noreferrer noreferrer" target="_blank">parser-combinators</a>:<br><br>> <span style="font-family:sans-serif;font-size:13px;color:rgb(0,0,0)">Due to the nature of the</span><span style="font-family:sans-serif;font-size:13px;color:rgb(0,0,0)"> </span><code style="font-size:13px;margin:0px;padding:0px;line-height:16.12px;font-family:monospace;color:rgb(0,0,0)"><a href="https://hackage.haskell.org/package/base-4.12.0.0/docs/Control-Applicative.html#t:Applicative" title="Control.Applicative" style="margin:0px;padding:0px;text-decoration-line:none;font-family:monospace;color:rgb(171,105,84)" rel="noreferrer noreferrer noreferrer" target="_blank">Applicative</a></code><span style="font-family:sans-serif;font-size:13px;color:rgb(0,0,0)"> </span><span style="font-family:sans-serif;font-size:13px;color:rgb(0,0,0)">and</span><span style="font-family:sans-serif;font-size:13px;color:rgb(0,0,0)"> </span><code style="font-size:13px;margin:0px;padding:0px;line-height:16.12px;font-family:monospace;color:rgb(0,0,0)"><a href="https://hackage.haskell.org/package/base-4.12.0.0/docs/Control-Applicative.html#t:Alternative" title="Control.Applicative" style="margin:0px;padding:0px;text-decoration-line:none;font-family:monospace;color:rgb(171,105,84)" rel="noreferrer noreferrer noreferrer" target="_blank">Alternative</a></code><span style="font-family:sans-serif;font-size:13px;color:rgb(0,0,0)"> </span><span style="font-family:sans-serif;font-size:13px;color:rgb(0,0,0)">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</span><span style="font-family:sans-serif;font-size:13px;color:rgb(0,0,0)"> </span><code style="font-size:13px;margin:0px;padding:0px;line-height:16.12px;font-family:monospace;color:rgb(0,0,0)"><a href="https://hackage.haskell.org/package/base-4.12.0.0/docs/Control-Applicative.html#t:Applicative" title="Control.Applicative" style="margin:0px;padding:0px;text-decoration-line:none;font-family:monospace;color:rgb(171,105,84)" rel="noreferrer noreferrer noreferrer" target="_blank">Applicative</a></code><span style="font-family:sans-serif;font-size:13px;color:rgb(0,0,0)"> </span><span style="font-family:sans-serif;font-size:13px;color:rgb(0,0,0)">and</span><span style="font-family:sans-serif;font-size:13px;color:rgb(0,0,0)"> </span><code style="font-size:13px;margin:0px;padding:0px;line-height:16.12px;font-family:monospace;color:rgb(0,0,0)"><a href="https://hackage.haskell.org/package/base-4.12.0.0/docs/Control-Applicative.html#t:Alternative" title="Control.Applicative" style="margin:0px;padding:0px;text-decoration-line:none;font-family:monospace;color:rgb(171,105,84)" rel="noreferrer noreferrer noreferrer" target="_blank">Alternative</a></code><span style="font-family:sans-serif;font-size:13px;color:rgb(0,0,0)">, please prefer</span><span style="font-family:sans-serif;font-size:13px;color:rgb(0,0,0)"> </span><a href="https://hackage.haskell.org/package/parser-combinators-1.2.1/docs/Control-Monad-Combinators.html" style="font-family:sans-serif;font-size:13px;margin:0px;padding:0px;text-decoration-line:none;color:rgb(171,105,84)" rel="noreferrer noreferrer noreferrer" target="_blank">Control.Monad.Combinators</a><span style="font-family:sans-serif;font-size:13px;color:rgb(0,0,0)"> </span><span style="font-family:sans-serif;font-size:13px;color:rgb(0,0,0)">instead when possible.</span><br><br>I have not verified it, but it is a bit worrying.<br><br>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)<br><br><br>======<br>Georgi</div>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" rel="noreferrer noreferrer noreferrer" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div>
</blockquote></div>
</blockquote></div>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank" rel="noreferrer">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div></div>
</blockquote></div>