FWIW- this is actually the behavior for shiftL. It should just 'do the right thing' for over-shifting, in that it just keeps shifting, resulting in For shiftR we work that way, but there is apparently a cut and paste error in the haddocks that makes shiftR have the warning from unsafeShiftR that its behavior on overflow is undefined.
unsafeShiftR 1 1000000 :: Int
1 This stays put because 1000000 `mod` 64 = 0, while
shiftR 1 1000000 :: Int
0 saturates as you'd expect from:
unsafeShiftL 1 1000000 :: Int
1
shiftL 1 1000000 :: Int
0
The fact that we work modulo the integer size for unsafeShiftL/unsafeShiftR
is very much platform specific though and its left deliberately
unspecified, as the current unsafeShiftL and unsafeShiftR are intended for
use in scenarios where the cost of the branch would be prohibitive, so
over-constraining their implementation would be quite bad.
The intention of the current specification should be that shiftR and shiftL
just shift and keep on shifting even if you give a number that is too big,
while unsafeShiftR and unsafeShiftL do undefined platform specific stuff
when you give them a number out of range, usually this will be the modular
shift that you get from the native instruction.
This way you can use unsafeShiftL and unsafeShiftR when you know the
argument is in range.
We should definitely fix the documentation for shiftR though. That it
claims to be undefined on over-shifting is just wrong.
-Edward
On Sun, Jul 13, 2014 at 3:50 PM, David Feuer
That may be reasonable. I think it likely makes more sense than making the type of shift depend on the type of number, anyway. On Jul 13, 2014 3:43 PM, "Henning Thielemann" < schlepptop@henning-thielemann.de> wrote:
Am 13.07.2014 20:36, schrieb David Feuer:
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.
What kind of data do you have in mind, where both signed and unsigned shifts make sense?
So far, I'd say, that calling "asr" on Word and "lsr" on Int should be a type error.
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries