On Fri, Jul 27, 2012 at 3:42 PM, Ian Lynagh <span dir="ltr"><<a href="mailto:igloo@earth.li" target="_blank">igloo@earth.li</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Fri, Jul 27, 2012 at 03:06:04PM -0400, Edward Kmett wrote:<br>
> There is currently no way to know whether or not calling<br>
</div>> Data.Bits.bitSizewill crash your program.<br>
<div class="im">><br>
> I propose extending the Bits class to include:<br>
><br>
> hasBitSize :: Bits b => b -> Bool<br>
><br>
> such that it returns False for Integer and True for the other instances<br>
<br>
</div>Can you give an example of a situation in which you would use<br>
hasBitSize, and do something useful if it returned False?<br></blockquote><div><br></div><div>The following can only work if bitSize is well defined.</div><div><br></div><div>traverseBits :: (Applicative f, Bits b) => (Bool -> f Bool) -> b -> f b </div>
<div>traverseBits f b = snd . Prelude.foldr step (bitSize b - 1,0) <$> traverse (f . testBit b) [0 .. bitSize b - 1] where</div><div> step True (n,r) = (n - 1, setBit r n)</div><div> step _ (n,r) = (n - 1, r)</div>
<div> </div><div>to work around this I've had to use:</div><div><br></div><div><div>traverseBits :: (Applicative f, Bits b) => (Bool -> f Bool) -> b -> f b </div><div>traverseBits f b = Prelude.foldr step 0 <$> traverse g bits</div>
<div> where</div><div> g n = (,) n <$> f (testBit b n)</div><div> bits = Prelude.takeWhile hasBit [0..]</div><div> hasBit n = complementBit b n /= b -- test to make sure that complementing this bit actually changes the value</div>
<div> step (n,True) r = setBit r n</div><div> step _ r = r</div></div><div><br></div><div>where I'm manually probing each bit to see that changing it changes the value.</div><div><br></div><div>Used with the other combinators in lens the former just crashes when you use</div>
<div><br></div><div><div><div>foldMapOf :: ((c -> Const m d) -> a -> Const m b) -> (c -> m) -> a -> m</div></div><div>foldMapOf l f = getConst . l (Const . f)</div></div><div><br></div><div>toListOf :: ((c -> Const [c] d) -> a -> Const [c] b) -> a -> [c]</div>
<div><div>toListOf l = foldMapOf l return</div></div><div><br></div><div>Now when we use it with an explicit signature both of these can do reasonable things:</div><div><br></div><div><div>ghci> toListOf traverseBits (5 :: Int)</div>
<div>[True,False,True,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False]</div>
<div><br></div><div>But with defaulting choosing Integer</div><div>ghci> toListOf traverseBits 5</div><div><br></div><div>the former instance will crash, whereas the latter properly returns an infinite lazy list</div><div>
<br></div><div>[True,False,True,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,...</div>
</div><div><br></div><div>It would be much nicer not to have to probe using complementBit creating ever larger temporary integers just to see if the list of valid bit positions hadn't been exhausted.</div><div><br></div>
<div>Then I could test at the start to know whether I should use [0..] or [0..bitSize-1] and get away with much less code and much less unnecessary memory allocation.</div><div><br></div><div>-Edward</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Would it be better to move bitSize into a separate class?</blockquote><div><br></div><div>I don't think so. Ultimately, you should be able to know for every numeric type if it has a fixed or variable number of bits. In a perfect world 'd rather just have bitSize return a Maybe that way we don't have to truck with partial functions in the API. </div>
<div><br></div><div>However, the case for just adding hasBitSize is that it avoids breaking existing code.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
> since the vast majority of instances are finite, it may be reasonable to<br>
> set the default definition to<br>
><br>
> hasBitSize _ = False<br>
<br>
</div>Did you mean True?<br></blockquote><div> </div><div>Yes</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Either way, I think I would personally prefer not to have a default, so<br>
that people need to actually check existing instances.</blockquote><div><br></div><div>Also perfectly reasonable. </div><div><br></div><div>-Edward</div></div>