<div dir="ltr"><div><font face="arial, sans-serif"><br></font></div><font face="arial, sans-serif"><span style="color:rgb(0,0,0)">At </span>

<i style="color:rgb(0,0,0)">Fri Oct 1 01:42:39 UTC 2021</i>  <span style="color:rgb(0,0,0)">Ben Franksen wrote</span><br></font><div><pre style="white-space:pre-wrap;color:rgb(0,0,0)"><font face="arial, sans-serif"><font size="2">>> Am 17.09.21 um 07:15 schrieb Michael Turner:
</font>>><i> 
</i>>><i> "The contribution of each element to the final result is combined with an
</i>>><i>     accumulator via an /operator/ function.  The operator may be explicitly
</i>>><i>     provided by the caller as in `foldr` or may be implicit as in `length`. In
</i>>><i>     the case of `foldMap`, the caller provides a function mapping each element
</i>>><i>     into a suitable 'Monoid', which makes it possible to merge the per-element
</i>>><i>     contributions via that monoid's `mappend` function."
</i>><i> 
</i>>><i> This is a little better, but I'd write it this way, I think.
</i>>><i> 
</i>>><i> "Folds take operators as arguments. In some cases, it's implicit, as
</i>>><i> in the function "length". These operators are applied to elements when
</i>>><i> lazy evaluation requires it, with a fold 'accumulator' as one of the
</i>>><i> operands. 'foldMap' uses a function (implicit? explicit?) that maps
</i>>><i> elements into . . . ."
</i>
> The problem you two are both facing is this: you want to describe, 
> abstractly, generally, the common principle behind an ad-hoc 
> lumped-together set of functions. This is very likely to result in 
> contortions and provides you with no insight.</font></pre><pre style="white-space:pre-wrap;color:rgb(0,0,0)"><font face="arial, sans-serif"><br></font></pre><pre style="white-space:pre-wrap;color:rgb(0,0,0)"><font face="arial, sans-serif">I think neither "ad-hoc" nor "lumped-together" is accurate.</font></pre><pre style="white-space:pre-wrap;color:rgb(0,0,0)"><font face="arial, sans-serif">For both `Functor t` and `Foldable t` the metaphor is `t` as container.</font></pre><pre style="white-space:pre-wrap;color:rgb(0,0,0)"><font face="arial, sans-serif">* For `Functor` we wish to preserve the shape/spine and mangle each element irrespective of other content.</font></pre><pre style="white-space:pre-wrap;color:rgb(0,0,0)"><font face="arial, sans-serif">* For `Foldable` we wish to throw away the shape/spine and return some characteristic of the contents-as-a-whole.</font></pre><pre style="white-space:pre-wrap;color:rgb(0,0,0)"><font face="arial, sans-serif">(The fold is possibly returning another container/contents, but it won't necessarily be the same `t`; even if it is, the result won't be the same shape/spine.)</font></pre><pre style="white-space:pre-wrap;color:rgb(0,0,0)"><font face="arial, sans-serif"><br></font></pre><pre style="white-space:pre-wrap;color:rgb(0,0,0)"><font face="arial, sans-serif">There are some frequent use-cases for "characteristic of the contents-as-a-whole": count, sum, min/max, is-element. So it makes sense to provide (possibly optimised) methods. Yes the insight is that there's a common principle. But the optimising devil is in the detail.</font></pre><pre style="white-space:pre-wrap;color:rgb(0,0,0)"><font face="arial, sans-serif">The devilish detail is that although we're going to throw away the shape/spine, knowing its organising principle will help navigating it effectively. Otherwise we could stick with List as container -- but as Ref [1] points out, that's hardly ever wise.</font></pre><pre style="white-space:pre-wrap;color:rgb(0,0,0)"><font face="arial, sans-serif">For somebody coming to the docos to generate their own `instance Foldable`, thinking in terms of `toList` might help in getting the right result; it won't explain why they'd want to use something other than a List.</font></pre></div></div>