On Jul 13, 2014 3:30 PM, "John Meacham"
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)