Proposal: Add hasBitSize to Data.Bits.Bits

[Edward Kmett]

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
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20120923/f15fd879/attachment-0001.htm>