<div>It is associativity that is required, not commutativity (in addition to the fact that the list is finite).</div>
<div> </div>
<div>This is why Data.Foldable provides operations for monoids over containers. Monoids just provide you with associativity and a unit, which lets you reparenthesize the fold however you want.</div>
<div> </div>
<div>See the monoids library or my slides from hac-phi for lots of (ab)uses of a monoid&#39;s associativity.</div>
<div> </div>
<div><a href="http://comonad.com/reader/2009/hac-phi-slides/">http://comonad.com/reader/2009/hac-phi-slides/</a></div>
<div> </div>
<div>-Edward Kmett<br><br></div>
<div class="gmail_quote">On Wed, Aug 19, 2009 at 10:32 AM, Eugene Kirpichov <span dir="ltr">&lt;<a href="mailto:ekirpichov@gmail.com">ekirpichov@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">2009/8/19 Dan Doel &lt;<a href="mailto:dan.doel@gmail.com">dan.doel@gmail.com</a>&gt;:<br>
<div class="im">&gt; On Wednesday 19 August 2009 12:14:24 am Jason McCarty wrote:<br>&gt;&gt; Interestingly, foldM can also be written as a left fold. To see this, note<br>&gt;&gt; that it is a theorem that foldr f z xs = foldl f z xs as long as f is<br>
&gt;&gt; associative and z is a unit for f.<br>&gt;<br><br></div>This is not true: f has to be commutative, not associative.<br><br>Consider matrix multiplication.<br>
<div class="im"><br>&gt; It must also be the case that xs is finite in length, because if it is<br>&gt; infinite, then &#39;foldl f z xs&#39; is bottom, while &#39;foldr f z xs&#39; needn&#39;t be. This<br>&gt; difference holds over into foldM implemented with each, where you can write<br>
&gt; something like:<br>&gt;<br>&gt;  foldM (\f e -&gt; if even e then Left (show e) else Right f) &quot;no evens&quot; [1..]<br>&gt;<br>&gt; and get an answer of &#39;Left &quot;2&quot;&#39; with a foldr implementation, but bottom with a<br>
&gt; foldl implementation.<br>&gt;<br>&gt; This potentially translates into its own performance concerns, because in such<br>&gt; monads, the computation can short-circuit upon finding a &#39;throw&#39; when using<br>&gt; the foldr implementation, but with the foldl implementation, you have to do at<br>
&gt; least a little shuffling of thunks for the entire list.<br>&gt;<br>&gt; -- Dan<br>&gt; _______________________________________________<br>&gt; Haskell-Cafe mailing list<br>&gt; <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
&gt; <a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>&gt;<br><br><br><br></div><font color="#888888">--<br>Eugene Kirpichov<br>Web IR developer, <a href="http://market.yandex.ru/" target="_blank">market.yandex.ru</a><br>
</font>
<div>
<div></div>
<div class="h5">_______________________________________________<br>Haskell-Cafe mailing list<br><a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br><a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</div></div></blockquote></div><br>