Proposal: Add hasBitSize to Data.Bits.Bits

[Thomas DuBuisson]

On Sun, Jul 29, 2012 at 8:37 AM, Thomas Schilling
<nominolo at googlemail.com> wrote:
> To make sure I understand this correctly:
>
> The current problem is that bitSize is a partial function *depending
> on the type* of its argument (currently it always returns _|_ for
> Integer, and is total for any other type). That does indeed seem like
> a Bad Idea.
>
> You propose to:
>
>   1. Remove "bitSize" from the Bits class.
>   2. Add a new class BitSize which only contains the "bitSize" method.
> Integer would not be an instance of this class.

Yes, that is the solution I would support.

> So, then:
>
>   - I assume we want a deprecation cycle.  How, will that work?

I don't have a good answer to this question.  I'd support the change
even without a normal deprecation cycle, but I'm more flexible than
some.

>   - Do we have a formal definition of what bitSize means? E.g.,
> could/should a (finite) ByteString be made an instance of this?

I think bitSize is already defined as to mean the number of bits used
in the representation of the value.  There are no padding bits and it
does not depend on the value (so passing "undefined :: T" should work
for all instances).  This means ByteString could not be a reasonable
instance.  If, OTOH, we had reifyable type level numerics and a
ByteString-like type that encoded it's length in the type then this
could be an instance.

-The other Thomas