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

On Sep 29, 2014, at 12:21 PM, Gershom B wrote:

...

On Mon, Sep 29, 2014 at 11:19 AM, David Feuer wrote:

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 don't think that bits is designed to "provide a uniform interface to fast bitwise operations on short bitvectors". It is designed to provide uniform operations over datatypes that can be treated as a sequence of bits. In general, it seems to do this just fine. All operations we define in our core libraries, should, by default, have two properties: 1) They are efficient, 2) They are maximally defined; i.e. they produce bottom as infrequently as possible. The latter property, in general, should constrain the former. This proposal is to make a default implementation violate my expectations by asking, in the name of _sometimes_ efficiency, that it be less general than it can be, and produce nonterminating results when _otherwise_ it might terminate.

Are you then proposing that we make the other Bits instances lazier? Your argument is well-stated, and this discussion is quite interesting, so I really don't mean that question rhetorically. We clearly could test an individual CInt before applying a binary operation, and I support the notion of adding such an operation somewhere. But I wouldn't support removing the current behavior, which is why I then come down on Bool differently than you. Anthony

I don't think either condition is necessary. If somebody wants "extra strict" operations on bool, they can define those in an external package. I don't feel it is a common enough use case to go into base. Furthermore, I don't see explicitly documenting that something is subject to change when it may well be that its fine and there's no reason to change it.

I can think of three uses for the Bool instance for bits. First, because `xor` may be a more clear name than (/=) for a use of Bool. Second, to test a generic operation on Bits in a minimal context as a "sanity check". Third, because I may wish to write _logical operations_ in a manner polymorphic over my "bool-like" type. In the first two cases, the existing behaviour is fine. In the last case, it is a net positive.

In the continued absence of any good arguments for why we _should_ make this change, at this point I'm a firm -1.

-g