<div dir="ltr">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.<div><br></div></div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Sep 18, 2013 at 8:07 AM, Herbert Valerio Riedel <span dir="ltr"><<a href="mailto:hvr@gnu.org" target="_blank">hvr@gnu.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 2013-09-18 at 13:56:22 +0200, Herbert Valerio Riedel wrote:<br>
<br>
[...]<br>
<br>
> As it stands, the current implementation state is at<br>
><br>
>  <a href="http://git.haskell.org/packages/base.git/commitdiff/cddc9024e67a6d4c01bb190839d0134af8c907e0" target="_blank">http://git.haskell.org/packages/base.git/commitdiff/cddc9024e67a6d4c01bb190839d0134af8c907e0</a><br>

><br>
> Now I have two questions:<br>
><br>
>  1.) Currently, bitSizeMaybe and bitSize have no default implementation<br>
>      defined. Shall we define mutually recursive default implementations<br>
>      for these two functions to help smooth the transition?<br>
><br>
>      e.g. in the style (just an example, not an actual proposal) of:<br>
><br>
>        bitSize = fromJust . bitSizeMaybe<br>
><br>
>        bitSizeMaybe = Just . bitSize<br>
><br>
><br>
>  2.) As it's probably not to late to easily fix any bikeshedding/naming<br>
>      issues: Shall the naming remain as implemented?<br>
<br>
PS:<br>
<br>
  3.) What's the benefit of having the super-class constraint on<br>
<br>
        class Bits b => FiniteBits b where<br>
            finiteBitSize :: b -> Int<br>
<br>
      ?<br>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/mailman/listinfo/libraries</a><br>
</blockquote></div><br></div>