Proposal: change the Bits instance for Bool to align with other basic types and support branchless calculations

[David Feuer]

On Sep 29, 2014 10:46 AM, "Edward Kmett" <ekmett at 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.

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140929/c7061cf6/attachment.html>