Bit shifting limitations

[David Feuer]

On Jul 13, 2014 3:30 PM, "John Meacham" <john at repetae.net> wrote:
>
> definitely.
>
> I would much prefer to respecify shiftR and shiftL as masked in
> nature, that is a much better state of affairs than calling error and
> easier to arrange for arches that don't natively act that way.

They don't call error when given large counts; they give zero or -1. This
is a pleasant property that we probably want to offer; it's just not
(apparently) what CPUs tend to offer, and isn't always desirable.

> Another advantage of logical and arithmetic shifts is that there would
> be easier to get rid of the pesky 'Num' superclass as you wouldn't
> need Word/Int trickery and depending on dubious fromIntegaral behavior
> to get the one you want.

Yes, exactly. I wouldn't want to change the current behavior, I don't
think, but rather add more functions.

> I am not entirely pleased with this as the Num superclass still
> exists; users won't know to define both arithmetic and logical and
> there isn't an easy way to create defaults for them while keeping
> backwards compatibility. Once class aliases are fully integrated then
> this will be straigtforward to solve in a backwards compatible manner.
> It is still better than the alternative though.

I have no idea what any of that means, but it should be easy to create
defaults using isSigned. Something vaguely like

ShiftRArithmetic x c = if (isSigned x)
                                      then shiftR x c
                                      else (-1 `shiftR` c) .|. (x `shiftR`
c)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140713/93c0f7d2/attachment.html>