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.

-Edward

On Sun, Sep 28, 2014 at 1:15 PM, David Feuer <david.feuer@gmail.com> 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?