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

Edward Kmett ekmett at
Sun Sep 28 17:34:18 UTC 2014

Let's factor your proposal into two pieces, creating branchless boolean
operations and using them in Data.Bits.

I'm 100% on board with adding a combinator for fast non-short-circuiting
boolean and' and or' to Data.Bool.

I'm not yet convinced that the thing in Data.Bits should be that operation
rather than the safer choice.

That turn your argument around on you to some extent. You'd have the fast
branchless version as and' and or' and when you are working monomorphically
with booleans and want short-circuiting behavior you can reach for them. ;)

Why am I being a pain in the ass about this?

I can envision a point in Haskell's future where we might want to let the
combinators in Data.Bits be the ones we use for Bool, where
&&/||/and/or/any/all/not/ just smash things together with Bits and we
generalize more of base.

That would be an incredibly dumb thing to do with non-short-circuiting
versions of the operators.

I for one don't want to cut off that possible future for a 10% gain for a
limited usecase.

I'm not willing to say we should do make that generalization, but I'm also
not willing to cut off that possible future.


On Sun, Sep 28, 2014 at 1:15 PM, David Feuer <david.feuer at> wrote:

> 10% sounds pretty big to me when you're trying to really squeeze out a bit
> more performance (which is what tends to lead people to even look at
> Data.Bits). The asymptotic hit, as you call it, will only hit you if you
> use what I consider to be the wrong operator. Why would you use .&. and .|.
> if what you want are && and ||? From the perspective of the Bits concept,
> Bool is a bitvector that happens to hold only one bit. Why would you expect
> that to short-circuit? Why would you use it for control flow?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list