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

[Edward Kmett]

On Mon, Sep 29, 2014 at 11:19 AM, David Feuer <david.feuer at gmail.com> wrote:

>
> 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.
>
I'd go for that.

> > 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 ...
>
Touché.

> > 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.
>
But if it is only intended for ad hoc overloading at known concrete
instances then the uniformity argument doesn't hold.

It is really for the higher order "generalized fun" use case that your
argument is strongest. ;)

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