Proposal: Add hasBitSize to Data.Bits.Bits

[Ben Millwood]

Well, okay, fair enough. The way you originally phrased it made it
sound like the current design was a problem that we regrettably had to
live with, but if it's actually what you want then I won't argue with
that.

In which case FixedBits sounds like a good idea. I don't think
FiniteBits is sufficiently bad an idea to worry about it, though.
(In any case, I'm not sure Henning's assertion that strict types have
finite bits is correct: after all, bitSize appears to be about the
capacity of the type, rather than how many bits it uses, so in the
case of Integer there is no finite size limit).

On Mon, Sep 24, 2012 at 4:42 AM, Edward Kmett <ekmett at gmail.com> wrote:
>
> On Sun, Sep 23, 2012 at 8:53 PM, Ben Millwood <haskell at benmachine.co.uk>
> wrote:
>>
>> 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 :)
>
>
> I'm rather strongly against this idea. Personally, I think a version of this
> that counts up "how many bits something actually has given a particular
> value" is a very different operation. Every application I currently have
> quite frankly doesn't have a value lying around to pass and it would render
> the operation useless to many (most?) of its current consumers.
>
> A large part of the motivation for the second method was that it didn't have
> to box and unbox a Maybe, e.g. for HAMTs, that may not know the number of
> bits they can fit in, say, an Int on a given platform and many of the
> combinators are constructing an mask out of whole cloth given only the type.
>
> It strikes me as a bit of a rule of thumb on what is in base that the
> classes that are there are the things needed to implement the types that are
> there. There currently isn't a type in base that needs this extra behavior,
> so I think it would be reasonable that the method and class live in a module
> related somehow to the use-case. I don't object to creating yet another
> class somewhere.
>
> I just don't know that it belongs in base or should complicate an already
> complicated proposal/implementation, and I definitely think it is a
> different method than the one we've been talking about so far.
>
> -Edward
>
>>
>> (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 <ekmett at gmail.com> 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
>> > <haskell at benmachine.co.uk>
>> > 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
>> >> <lemming at henning-thielemann.de> 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 at haskell.org
>> >> > http://www.haskell.org/mailman/listinfo/libraries
>> >>
>> >> _______________________________________________
>> >> Libraries mailing list
>> >> Libraries at haskell.org
>> >> http://www.haskell.org/mailman/listinfo/libraries
>> >
>> >
>
>