<div dir="ltr">Actually you can implement them in terms of foldMap and they suffer somewhat less and become slightly more defined for infinite traversals but there is still some suffering to be had performance wise.<div><br>
</div><div>Snoyman has also been pursuing a monomorphic Foldable class, and there is one (more or less) in both my monoids and reducers packages, so this is an oft reinvented idea. ;)</div></div><div class="gmail_extra"><br>
<br><div class="gmail_quote">On Wed, Sep 11, 2013 at 4:05 PM, John Lato <span dir="ltr"><<a href="mailto:jwlato@gmail.com" target="_blank">jwlato@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div><div>I agree with everything Edward has said already. I went through a
similar chain of reasoning a few years ago when I started using
ListLike, which provides a FoldableLL class (although it uses fundeps as
ListLike predates type families). ByteString can't be a Foldable instance, nor do I think most people would want it to be.<br><br></div><div>Even though I would also like to see mapM_ in bytestring, it's probably faster to have a library with a separate monomorphic Foldable class. So I just wrote one:<br>
<br><a href="https://github.com/JohnLato/mono-foldable" target="_blank">https://github.com/JohnLato/mono-foldable</a><br><a href="http://hackage.haskell.org/package/mono-foldable" target="_blank">http://hackage.haskell.org/package/mono-foldable</a><br>
</div>
<div><br></div>Petr Pudlak has done some work in this area. A big problem is that foldM/mapM_ are typically implemented in terms of Foldable.foldr (or FoldableLL), but this isn't always optimal for performance. They really need to be part of the type class so that different container types can have specialized implementations. I did that in mono-foldable, using Artyom's map implementation (Artyom, please let me know if you object to this!)<br>
<br></div><div>pull requests, forks, etc all welcome.<br></div><div><br></div><div>John L.<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div class="h5">On Wed, Sep 11, 2013 at 1:29 PM, Edward Kmett <span dir="ltr"><<a href="mailto:ekmett@gmail.com" target="_blank">ekmett@gmail.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr">mapM_ is actually implemented in terms of Foldable, not Traversable, and its implementation in terms of folding a ByteString is actually rather slow in my experience doing so inside lens and isn't much faster than the naive version that was suggested at the start of this discussion.<div>
<br></div><div>But as we're not monomorphizing Foldable/Traversable, this isn't a think that is able to happen anyways.<span><font color="#888888"><br><div><br></div><div>-Edward</div></font></span></div>
</div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Wed, Sep 11, 2013 at 2:25 PM, Henning Thielemann <span dir="ltr"><<a href="mailto:lemming@henning-thielemann.de" target="_blank">lemming@henning-thielemann.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
On Wed, 11 Sep 2013, Duncan Coutts wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
For mapM etc, personally I think a better solution would be if<br>
ByteString and Text and other specialised containers could be an<br>
instance of Foldable/Traversable. Those classes define mapM etc but<br>
currently they only work for containers that are polymorphic in their<br>
elements, so all specialised containers are excluded. I'm sure there<br>
must be a solution to that (I'd guess with type families) and that would<br>
be much nicer than adding mapM etc to bytestring itself. We would then<br>
just provide efficient instances for Foldable/Traversable.<br>
</blockquote>
<br></div>
I'd prefer to keep bytestring simple with respect to the number of type extensions. Since you must implement ByteString.mapM anyway, you can plug this into an instance definition of Traversable ByteString.<br>
</blockquote></div><br></div>
</div></div><br></div></div><div class="im">_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/mailman/listinfo/libraries</a><br>
<br></div></blockquote></div><br></div>
</blockquote></div><br></div>