<div dir="ltr">I think defining the behavior of shifts to work modulo the bitSize is no better than leaving those ranges undefined. If we were going to define what it means to shift outside that range I'd rather it was somehow consistent with math multiplying and dividing by powers of two than randomly rolling over to a world where shifting a Word32 by 33 somehow corresponds to shifting by 1.</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Jul 13, 2014 at 11:36 AM, David Feuer <span dir="ltr"><<a href="mailto:david.feuer@gmail.com" target="_blank">david.feuer@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>The current state of affairs is a bit unsatisfactory.<br><br>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:<br>

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

</div><div><br></div><div>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?<br><br></div><div>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.<span class="HOEnZb"><font color="#888888"><br>

<br>David<br></font></span></div></div>
<br>_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/mailman/listinfo/libraries</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Eric Mertens
</div>