Proposal: Remove Num superclass of Bits

[Johan Tibell]

On Sun, Oct 16, 2011 at 10:35 AM, Edward Kmett <ekmett at gmail.com> wrote:

> On Sun, Oct 16, 2011 at 1:45 AM, Isaac Dupree <
> ml at isaac.cedarswampstudios.org> wrote:
>
>> As others observed, "one" is only useful for the "bit" method default, and
>> might be meaningless for an "instance () Bits" (whereas the rest of the
>> class makes sense for () as a zero-bit instance, albeit a use doesn't come
>> to mind).  Or, similarly to (), a bit-vector which contains its length
>> statically in its type: it would be simpler if length zero was just as valid
>> as any other length.  And it would be a bit strange to define 'one' as a
>> value equal to 'zero'.
>>
>>
> It isn't entirely meaningless it is just out of range. It is perfectly well
> defined for me to set the 200th bit of a 64 bit integer, it just doesn't do
> anything. ;) Similarly setting the 1 bit of () would result in (), since
> there are no bits to set.
>

This is hard to implement in practice, as the behavior of assembly
instructions for bit manipulation isn't always defined on out of range
values and working around that problem in Haskell code will often involve a
bad performance trade-off (i.e. adding a branch). We have this problem with
shiftL/shiftR, which are terribly slow, leading to no-one using these
functions in production quality code (I think I've seen unsafeShiftL/R
implemented in at least 3-4 of our most commonly used libraries).

I suggest we hurry slowly here. Do we understand what the meaning of the
Bits class is? Lets make sure we don't make it harder for use for the
majority use case of performing bitwise operations on machine sized
quantities.

Cheers,
Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20111016/c407c1f8/attachment.htm>