Re: Proposal: Add hasBitSize to Data.Bits.Bits

Hold on, we /do/ get a different combinator, because we're introducing this new typeclass anyway, and bitSize is being deprecated. So why not stop excluding it from looking at its argument? Now's a better time than later to do so :) (Sorry this is late; I was originally going to comment to Henning that we hadn't necessarily agreed on Fixed because of my argument, but then realised someone had objected to my argument, but then realised that that objection was possibly invalid). On Tue, Aug 28, 2012 at 6:18 PM, Edward Kmett wrote:

The problem is that right now bitSize is deliberately excluded from looking at its argument to determine the number of bits in it. You _really_ want a different combinator. Almost every user of bitSize is passing it undefined, not a real value.

On Tue, Aug 28, 2012 at 12:07 PM, Ben Millwood wrote:

...

Wouldn't it be possible to have an instance Bits ByteString, or Vector Bool or something, where the bitsize would depend on the bytestring length, and hence wouldn't be fixed?

(although if we're catering for that sort of use, the docs will need to be changed)

On Sun, Aug 26, 2012 at 9:53 PM, Henning Thielemann wrote:

...

On Sun, 26 Aug 2012, Ian Lynagh wrote:

...

On Wed, Aug 22, 2012 at 07:49:49PM -0400, Edward Kmett wrote:

...

deprecate, but not remove bitSize this iteration, and make a separate class FiniteBits for things with a finite, fixed number of bits:

...

class Bits b => FiniteBits b where finiteBitSize :: b -> Int finiteBitSize = bitSize

Bit size is always finite in strict data types, isn't it? I suggest a name containing "Fixed".

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries