Bit shifting limitations

[David Feuer]

The current state of affairs is a bit unsatisfactory.

1. The biggest problem, as I see it, is that while we have shiftR and
shiftL, which are documented as giving 0 or -1 when shifting too far, and
we have unsafeShiftR and unsafeShiftL, which are likely to do whatever the
CPU happens to do, we don't have anything guaranteed to shift using just
the first five or six bits of the shift count, which is what Java specifies
and what unsafeShiftR and unsafeShiftL *actually* do (at least on x86_64).
I propose that we add these masked shifts to Data.Bits. The default
implementations can look something like:

shiftRMasked x count
  | popCount (finiteBitSize x) != 1 = error "Masked shift only makes sense
if the size is a power of 2."
  | otherwise = x `unsafeShiftR` (count .&. (finiteBitSize x - 1))

2. It would be nice to specify what shiftR and shiftL are supposed to do
when given negative shift counts. Is there a practical reason not to
specify that?

3. I would like to add explicit arithmetic and logical shifts to Data.Bits.
When fiddling bits, it's often easier to think about that distinction
explicitly, rather than in terms of whether the type is signed or unsigned,
and more convenient to have an explicit operation rather than casting
around.

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140713/aa4400c5/attachment.html>