On Sun, Jul 29, 2012 at 8:37 AM, Thomas Schilling
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