<p dir="ltr">It's intentional. The behavior makes sense (although it's a bit unintuitive at first) and follows common mathematical convention.</p>
<p dir="ltr">For one, it makes sense logically: it is vacuously true that every element of an empty list satisfies any predicate. That's how forall works normally. Think about it by analogy to implication: false implies anything (ie False -> a is true no matter what a is).</p>
<p dir="ltr">It also makes sense when looking at these as a fold: the folding operation is && and True is the identity element for &&. In a broad sense, True is naturally the "empty" case for && so that's where we start from. It's the same for say sum (an empty sum is 0) and product (an empty product is 1).</p>
<p dir="ltr">From a practical standpoint, this default neatly avoids a bunch of special cases, meaning we don't have to check if a list is empty before aggregating it. It's something that's worth understanding and relying in because it makes your code simpler and more regular.</p>
<div class="gmail_quote">On Sep 29, 2015 14:33, "Lana Black" <lanablack@amok.cc> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
Is there any particular reason why the 'all' function returns True when<br>
supplied with an empty list (or any other foldable)? I'm aware that it<br>
is implemented via All monoid instance, my question is whether this<br>
behaviour is intentional or it can be considered a bug.<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
</blockquote></div>