I believe the resolution was to explicitly leave bitSizeMaybe _not_ implemented in terms of bitSize to help ensure it gets filled in correctly.

Im rather neutral on whether we should supply a definition in the other direction.

-Edward


On Wed, Sep 18, 2013 at 7:56 AM, Herbert Valerio Riedel <hvr@gnu.org> wrote:
On 2012-09-24 at 01:28:20 +0200, Henning Thielemann wrote:
>> On Wed, Aug 22, 2012 at 07:49:49PM -0400, Edward Kmett wrote:
>>> We want to add
>>>
>>>> class Bits b where
>>>>     bitSizeMaybe :: b -> Maybe Int
>>>
>>> and 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
>>
>> I've just pushed a patch implementing what I think the conclusion was.
>> Please let me know if you think I got it wrong.
>
> My last comment was, that FiniteBits is not an appropriate name, and
> then we arrived at FixedBits:
>    http://www.haskell.org/pipermail/libraries/2012-August/018349.html

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?

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