Proposal: Add hasBitSize to Data.Bits.Bits

[Edward Kmett]

Throwing Integer out of Bits seems more prone to induce breakage than providing a more accurate type for bitSize -- I know at least one of my modules for working with boolean rings would have be scrapped.

It is also likely to force users who wanted the bit operations they already had on Integer to create wonky local instances to get back behavior the previously had available. 

Given my druthers at this point I'd go for:

Making a subclass to move the existing bitSize to, replete with a default definition.

class Bits b => FiniteBits b where
   bitSize :: b -> Int
   bitSize = fromJust . perhapsBitSize

and adding the perhapsBitSize Lennart suggested to BitSize to replace the moved bitSize:

class Bits b where
    perhapsBitSize :: b -> Maybe Int
    ...

Then code that only works for finite cases can use bitSize, code that already worked with infinite cases that never touched bitSize can continue to work, existing users that called bitSize but could only handle finite cases can change to FiniteBits and doesn't need to take a performance hit or fiddling with the Just constructor, and code that can work for the infinite case if it didn't crap out with bottom can safely upgrade to perhapsBitSize.

I am not wedded to the perhapsBitSize name. I am wedded to not losing existing functionality unnecessarily, however.

Sent from my iPhone

On Aug 13, 2012, at 6:13 PM, Johan Tibell <johan.tibell at gmail.com> wrote:

> On Mon, Aug 13, 2012 at 2:48 PM, Henning Thielemann
> <lemming at henning-thielemann.de> wrote:
>> How about two versions of 'bitSize' - one with Maybe return type in the Bits
>> class and one without Maybe in a FixedBitSize subclass?
> 
> Is this worth breaking existing users of bitSize over? If anything it
> seems more worthwhile to throw out Integer from the Bits class and
> declare Bits to be for fixed sized entities.