<div dir="ltr">That&#39;s really funny timing. I started work on a very similar project just this week:<div><br></div><div><a href="https://github.com/snoyberg/mono-traversable" target="_blank">https://github.com/snoyberg/mono-traversable</a><br>


</div><div><br></div><div>It&#39;s not refined yet, which is why I haven&#39;t discussed it too publicly, but it&#39;s probably at the point where some review would make sense. There&#39;s been a bit of a discussion on a separate Github issue[1] about it.</div>


<div><br></div><div>A few caveats:</div><div><ul><li>The names are completely up for debate, many of them could be improved.<br></li><li>The laws aren&#39;t documented yet, but they mirror the laws for the polymorphic classes these classes are based on.</li>

<li>The Data.MonoTraversable module is the main module to look at. The other two are far more nascent (though I&#39;d definitely appreciate feedback people have on them).</li></ul><div>I think this and mono-foldable have a lot of overlap, I&#39;d be interested to hear what you think in particular John.</div>

</div><div><br></div><div>Michael</div><div><br></div><div>[1] <a href="https://github.com/snoyberg/classy-prelude/issues/18" target="_blank">https://github.com/snoyberg/classy-prelude/issues/18</a></div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Sep 11, 2013 at 11:05 PM, John Lato <span dir="ltr">&lt;<a href="mailto:jwlato@gmail.com" target="_blank">jwlato@gmail.com</a>&gt;</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&#39;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&#39;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&#39;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&#39;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">&lt;<a href="mailto:ekmett@gmail.com" target="_blank">ekmett@gmail.com</a>&gt;</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&#39;t much faster than the naive version that was suggested at the start of this discussion.<div>



<br></div><div>But as we&#39;re not monomorphizing Foldable/Traversable, this isn&#39;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">&lt;<a href="mailto:lemming@henning-thielemann.de" target="_blank">lemming@henning-thielemann.de</a>&gt;</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&#39;m sure there<br>
must be a solution to that (I&#39;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&#39;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>
<br>_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org">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></blockquote></div><br></div></div>