bitSize/bitSizeMaybe

Edward Kmett ekmett at gmail.com
Wed Sep 18 17:18:48 CEST 2013


The benefit is that it makes it clear that the notion of Bits and
FiniteBits are related and prevents you from winding up with signatures
that look like (Bits b, FiniteBits b) everywhere.



On Wed, Sep 18, 2013 at 8:07 AM, Herbert Valerio Riedel <hvr at gnu.org> wrote:

> On 2013-09-18 at 13:56:22 +0200, Herbert Valerio Riedel wrote:
>
> [...]
>
> > As it stands, the current implementation state is at
> >
> >
> http://git.haskell.org/packages/base.git/commitdiff/cddc9024e67a6d4c01bb190839d0134af8c907e0
> >
> > Now I have two questions:
> >
> >  1.) Currently, bitSizeMaybe and bitSize have no default implementation
> >      defined. Shall we define mutually recursive default implementations
> >      for these two functions to help smooth the transition?
> >
> >      e.g. in the style (just an example, not an actual proposal) of:
> >
> >        bitSize = fromJust . bitSizeMaybe
> >
> >        bitSizeMaybe = Just . bitSize
> >
> >
> >  2.) As it's probably not to late to easily fix any bikeshedding/naming
> >      issues: Shall the naming remain as implemented?
>
> PS:
>
>   3.) What's the benefit of having the super-class constraint on
>
>         class Bits b => FiniteBits b where
>             finiteBitSize :: b -> Int
>
>       ?
> _______________________________________________
> 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/20130918/4769a052/attachment.htm>


More information about the Libraries mailing list