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

[Anthony Cowley]

> On Sep 29, 2014, at 12:21 PM, Gershom B <gershomb at gmail.com> wrote:
> 
>> On Mon, Sep 29, 2014 at 11:19 AM, David Feuer <david.feuer at gmail.com> 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