<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Sep 13, 2013 at 5:38 AM, Mario Blažević <span dir="ltr">&lt;<a href="mailto:blamario@acanac.net" target="_blank">blamario@acanac.net</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 09/11/13 19:37, John Lato wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I didn&#39;t see this message and replied privately to Michael earlier, so<br>
I&#39;m replicating my comments here.<br>
<br>
1.  Sooner or later I expect you&#39;ll want something like this:<br>
<br>
class LooseMap c el el&#39; where<br>
<br>
<br>
lMap :: (el -&gt; el&#39;) -&gt; c el -&gt; c el&#39;<br>
<br>
It covers the case of things like hashmaps/unboxed vectors that have<br>
class constraints on elements.  Although maybe LooseFunctor or LFunctor<br>
is a better name.<br>
<br>
Probably something similar for Traversable would be good also, as would<br>
a default instance in terms of Functor.<br>
<br>
2.  IMHO cMapM_ (and related) should be part of the Foldable class.<br>
This is entirely for performance reasons, but there&#39;s no downside since<br>
you can just provide a default instance.<br>
<br>
3.  I&#39;m not entirely sure that the length* functions belong here.  I<br>
understand why, and I think it&#39;s sensible reasoning, and I don&#39;t have a<br>
good argument against it, but I just don&#39;t like it.  With those, and<br>
mapM_-like functions, it seems that the foldable class is halfway to<br>
being another monolithic ListLike.  But I don&#39;t have any better ideas<br>
either.<br>
</blockquote>
<br></div>
        If monolithic classes bother you, my monoid-subclasses package manages to break down the functionality into several classes. One big difference is that everything is based off Monoid rather than Foldable, and that has some big effects on the interface.<br>


<br>
<br></blockquote><div><br></div><div>I&#39;d point out what I&#39;d consider a bigger difference: the type signatures have changed in a significant way. With MonoFoldable, folding on a ByteString would be:</div><div><br>

</div><div>    (Word8 -&gt; b -&gt; b) -&gt; b -&gt; ByteString -&gt; b</div><div><br></div><div>With monoid-subclasses, you get:</div><div><br></div><div>    (ByteString -&gt; b -&gt; b) -&gt; b -&gt; ByteString -&gt; b</div>

<div><br></div><div>There&#39;s certainly a performance issue to discuss, but I&#39;m more worried about semantics. Word8 tells me something very specific: I have one, and precisely one, octet. ByteString tells me I have anywhere from 0 to 2^32 or 2^64  octets. Yes, we know from context that it will always be of size one, but the type system can&#39;t enforce that invariant.</div>

<div><br></div><div>Michael</div></div></div></div>