On Sep 29, 2014 10:46 AM, "Edward Kmett" <ekmett@gmail.com> wrote:
>
> We currently as a culture tolerate wildly varying strictness in Num's (+), Applicative's (<*>), Monoid's mappend, etc.
>
> Keep in mind the strictness analyzer isn't going to see through those (or this) when you are working polymorphically.

Do we currently have a convincing case for using *anything* in Bits polymorphically? As far as I can tell, the primary purpose of Bits is to provide a uniform interface to fast bitwise operations on short bitvectors (e.g., Int, Word, etc.) with enough flexibility thrown in to handle things like multi-word bitvectors, and a few other things with varying degrees of grace. Your intuition (which seems generally to be very good) obviously suggests otherwise. I'd be perfectly happy to put this proposal on hold for at least a year to let you figure out what it is that *you* think Bits should be, under two conditions:

1. We add non-short-circuiting and, or, and xor, by some names, somewhere.
2. We explicitly document that the short-circuiting behavior of Bits operations for Bool is as yet completely unspecified and subject to change without notice.

> Should we require every Monoid's mappend to be strict in both to maybe get a few percentage points improvement on fold when you have a strict container? 

... slippery slope fallacy ...

> What distinguishes Bits in this regard?

Its purpose. As it was designed, Bits is *not* for the sort of higher-order generalized fun that you love but rather performance hacks with varying levels of ugliness. I'm 100% in favor of higher-order generalized fun classes being available; I just don't thing Bits is supposed to be one of them.