Proposal: Add hasBitSize to Data.Bits.Bits

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
44 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Proposal: Add hasBitSize to Data.Bits.Bits

Edward Kmett-2
There is currently no way to know whether or not calling Data.Bits.bitSize will crash your program.

I propose extending the Bits class to include:

hasBitSize :: Bits b => b -> Bool

such that it returns False for Integer and True for the other instances

since the vast majority of instances are finite, it may be reasonable to set the default definition to

hasBitSize _ = False

Discussion Period: 2 weeks

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Add hasBitSize to Data.Bits.Bits

Ian Lynagh
On Fri, Jul 27, 2012 at 03:06:04PM -0400, Edward Kmett wrote:
> There is currently no way to know whether or not calling
> Data.Bits.bitSizewill crash your program.
>
> I propose extending the Bits class to include:
>
> hasBitSize :: Bits b => b -> Bool
>
> such that it returns False for Integer and True for the other instances

Can you give an example of a situation in which you would use
hasBitSize, and do something useful if it returned False?

Would it be better to move bitSize into a separate class?

> since the vast majority of instances are finite, it may be reasonable to
> set the default definition to
>
> hasBitSize _ = False

Did you mean True?

Either way, I think I would personally prefer not to have a default, so
that people need to actually check existing instances.


Thanks
Ian


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Add hasBitSize to Data.Bits.Bits

Edward Kmett-2
On Fri, Jul 27, 2012 at 3:42 PM, Ian Lynagh <[hidden email]> wrote:
On Fri, Jul 27, 2012 at 03:06:04PM -0400, Edward Kmett wrote:
> There is currently no way to know whether or not calling
> Data.Bits.bitSizewill crash your program.
>
> I propose extending the Bits class to include:
>
> hasBitSize :: Bits b => b -> Bool
>
> such that it returns False for Integer and True for the other instances

Can you give an example of a situation in which you would use
hasBitSize, and do something useful if it returned False?

The following can only work if bitSize is well defined.

traverseBits :: (Applicative f, Bits b) => (Bool -> f Bool) -> b -> f b 
traverseBits f b = snd . Prelude.foldr step (bitSize b - 1,0) <$> traverse (f . testBit b) [0 .. bitSize b - 1] where
  step True (n,r) = (n - 1, setBit r n)
  step _    (n,r) = (n - 1, r)
 
to work around this I've had to use:

traverseBits :: (Applicative f, Bits b) => (Bool -> f Bool) -> b -> f b 
traverseBits f b = Prelude.foldr step 0 <$> traverse g bits
  where
    g n      = (,) n <$> f (testBit b n)
    bits     = Prelude.takeWhile hasBit [0..]
    hasBit n = complementBit b n /= b -- test to make sure that complementing this bit actually changes the value
    step (n,True) r = setBit r n
    step _        r = r

where I'm manually probing each bit to see that changing it changes the value.

Used with the other combinators in lens the former just crashes when you use

foldMapOf :: ((c -> Const m d) -> a -> Const m b) -> (c -> m) -> a -> m
foldMapOf l f = getConst . l (Const . f)

toListOf :: ((c -> Const [c] d) -> a -> Const [c] b) -> a -> [c]
toListOf l = foldMapOf l return

Now when we use it with an explicit signature both of these can do reasonable things:

ghci> toListOf traverseBits (5 :: Int)
[True,False,True,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False]

But with defaulting choosing Integer
ghci> toListOf traverseBits 5

the former instance will crash, whereas the latter properly returns an infinite lazy list

[True,False,True,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,...

It would be much nicer not to have to probe using complementBit creating ever larger temporary integers just to see if the list of valid bit positions hadn't been exhausted.

Then I could test at the start to know whether I should use [0..] or [0..bitSize-1] and get away with much less code and much less unnecessary memory allocation.

-Edward

Would it be better to move bitSize into a separate class?

I don't think so. Ultimately, you should be able to know for every numeric type if it has a fixed or variable number of bits. In a perfect world 'd rather just have bitSize return a Maybe that way we don't have to truck with partial functions in the API.  

However, the case for just adding hasBitSize is that it avoids breaking existing code.
 
> since the vast majority of instances are finite, it may be reasonable to
> set the default definition to
>
> hasBitSize _ = False

Did you mean True?
 
Yes
 
Either way, I think I would personally prefer not to have a default, so
that people need to actually check existing instances.

Also perfectly reasonable. 

-Edward

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Add hasBitSize to Data.Bits.Bits

John Lato-2
In reply to this post by Edward Kmett-2
> From: Edward Kmett <[hidden email]>
>
> On Fri, Jul 27, 2012 at 3:42 PM, Ian Lynagh <[hidden email]> wrote:
>
>> On Fri, Jul 27, 2012 at 03:06:04PM -0400, Edward Kmett wrote:
>> > There is currently no way to know whether or not calling
>> > Data.Bits.bitSizewill crash your program.
>> >
>> > I propose extending the Bits class to include:
>> >
>> > hasBitSize :: Bits b => b -> Bool
>> >
>> > such that it returns False for Integer and True for the other instances
>
> Would it be better to move bitSize into a separate class?
>
>
> I don't think so. Ultimately, you should be able to know for every numeric
> type if it has a fixed or variable number of bits. In a perfect world 'd
> rather just have bitSize return a Maybe that way we don't have to truck
> with partial functions in the API.
>
> However, the case for just adding hasBitSize is that it avoids breaking
> existing code.

Given that existing code using bitSize can already cause a crash when
used with Integer or other infinite types, wouldn't it be better to
break existing code so authors can fix (or at least examine) their use
of bitSize?

I'm in favor of changing the type of bitSize, although since none of
my code uses that function it's an easy position for me to take.

John L.

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Add hasBitSize to Data.Bits.Bits

Andreas Abel
On 28.07.12 4:40 PM, John Lato wrote:

>> From: Edward Kmett <[hidden email]>
>>
>> On Fri, Jul 27, 2012 at 3:42 PM, Ian Lynagh <[hidden email]> wrote:
>>
>>> On Fri, Jul 27, 2012 at 03:06:04PM -0400, Edward Kmett wrote:
>>>> There is currently no way to know whether or not calling
>>>> Data.Bits.bitSizewill crash your program.
>>>>
>>>> I propose extending the Bits class to include:
>>>>
>>>> hasBitSize :: Bits b => b -> Bool
>
> I'm in favor of changing the type of bitSize, although since none of
> my code uses that function it's an easy position for me to take.

+1.  The Haskellish solution would let return bitSize a Maybe.

--
Andreas Abel  <><      Du bist der geliebte Mensch.

Theoretical Computer Science, University of Munich
Oettingenstr. 67, D-80538 Munich, GERMANY

[hidden email]
http://www2.tcs.ifi.lmu.de/~abel/



_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Add hasBitSize to Data.Bits.Bits

Lennart Augustsson
Don't add hasBitSize, add perhapsBitSize (or some other name) which returns a Maybe, and then bitSize can be deprecated.

  -- Lennart

On Sat, Jul 28, 2012 at 5:57 PM, Andreas Abel <[hidden email]> wrote:
On 28.07.12 4:40 PM, John Lato wrote:
From: Edward Kmett <[hidden email]>

On Fri, Jul 27, 2012 at 3:42 PM, Ian Lynagh <[hidden email]> wrote:

On Fri, Jul 27, 2012 at 03:06:04PM -0400, Edward Kmett wrote:
There is currently no way to know whether or not calling
Data.Bits.bitSizewill crash your program.

I propose extending the Bits class to include:

hasBitSize :: Bits b => b -> Bool

I'm in favor of changing the type of bitSize, although since none of
my code uses that function it's an easy position for me to take.

+1.  The Haskellish solution would let return bitSize a Maybe.

--
Andreas Abel  <><      Du bist der geliebte Mensch.

Theoretical Computer Science, University of Munich
Oettingenstr. 67, D-80538 Munich, GERMANY

[hidden email]
http://www2.tcs.ifi.lmu.de/~abel/




_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Add hasBitSize to Data.Bits.Bits

Antoine Latter-2
In reply to this post by Andreas Abel
On Sat, Jul 28, 2012 at 11:57 AM, Andreas Abel <[hidden email]> wrote:

> On 28.07.12 4:40 PM, John Lato wrote:
>>>
>>> From: Edward Kmett <[hidden email]>
>>>
>>> On Fri, Jul 27, 2012 at 3:42 PM, Ian Lynagh <[hidden email]> wrote:
>>>
>>>> On Fri, Jul 27, 2012 at 03:06:04PM -0400, Edward Kmett wrote:
>>>>>
>>>>> There is currently no way to know whether or not calling
>>>>> Data.Bits.bitSizewill crash your program.
>>>>>
>>>>> I propose extending the Bits class to include:
>>>>>
>>>>> hasBitSize :: Bits b => b -> Bool
>>
>>
>> I'm in favor of changing the type of bitSize, although since none of
>> my code uses that function it's an easy position for me to take.
>
>
> +1.  The Haskellish solution would let return bitSize a Maybe.
>

Is 'bitSize' a useful function to use monomorphically? It seems a
waste and irritating to have it return Maybe if I'm not using
Integer.

Antoine

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Add hasBitSize to Data.Bits.Bits

Thomas DuBuisson
On Sat, Jul 28, 2012 at 5:33 PM, Antoine Latter <[hidden email]> wrote:

> On Sat, Jul 28, 2012 at 11:57 AM, Andreas Abel <[hidden email]> wrote:
>> On 28.07.12 4:40 PM, John Lato wrote:
>>>>
>>>> From: Edward Kmett <[hidden email]>
>>>>
>>>> On Fri, Jul 27, 2012 at 3:42 PM, Ian Lynagh <[hidden email]> wrote:
>>>>
>>>>> On Fri, Jul 27, 2012 at 03:06:04PM -0400, Edward Kmett wrote:
>>>>>>
>>>>>> There is currently no way to know whether or not calling
>>>>>> Data.Bits.bitSizewill crash your program.
>>>>>>
>>>>>> I propose extending the Bits class to include:
>>>>>>
>>>>>> hasBitSize :: Bits b => b -> Bool
>>>
>>>
>>> I'm in favor of changing the type of bitSize, although since none of
>>> my code uses that function it's an easy position for me to take.
>>
>>
>> +1.  The Haskellish solution would let return bitSize a Maybe.
>>
>
> Is 'bitSize' a useful function to use monomorphically? It seems a
> waste and irritating to have it return Maybe if I'm not using
> Integer.

That is a great point.  Most my uses of 'bitSize' are monomorphic and
Maybe would just be silly.  OTOH, I'd be more than happy to fix up any
polymorphic code to include a new BitSize constraint.

Thomas

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Add hasBitSize to Data.Bits.Bits

Thomas Schilling-2
On 29 July 2012 15:37, Thomas DuBuisson <[hidden email]> wrote:
>> Is 'bitSize' a useful function to use monomorphically? It seems a
>> waste and irritating to have it return Maybe if I'm not using
>> Integer.
>
> That is a great point.  Most my uses of 'bitSize' are monomorphic and
> Maybe would just be silly.  OTOH, I'd be more than happy to fix up any
> polymorphic code to include a new BitSize constraint.

To make sure I understand this correctly:

The current problem is that bitSize is a partial function *depending
on the type* of its argument (currently it always returns _|_ for
Integer, and is total for any other type). That does indeed seem like
a Bad Idea.

You propose to:

  1. Remove "bitSize" from the Bits class.
  2. Add a new class BitSize which only contains the "bitSize" method.
Integer would not be an instance of this class.

So, then:

  - I assume we want a deprecation cycle.  How, will that work?
  - Do we have a formal definition of what bitSize means? E.g.,
could/should a (finite) ByteString be made an instance of this?

/ Thomas

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Add hasBitSize to Data.Bits.Bits

Thomas DuBuisson
On Sun, Jul 29, 2012 at 8:37 AM, Thomas Schilling
<[hidden email]> wrote:

> To make sure I understand this correctly:
>
> The current problem is that bitSize is a partial function *depending
> on the type* of its argument (currently it always returns _|_ for
> Integer, and is total for any other type). That does indeed seem like
> a Bad Idea.
>
> You propose to:
>
>   1. Remove "bitSize" from the Bits class.
>   2. Add a new class BitSize which only contains the "bitSize" method.
> Integer would not be an instance of this class.

Yes, that is the solution I would support.

> So, then:
>
>   - I assume we want a deprecation cycle.  How, will that work?

I don't have a good answer to this question.  I'd support the change
even without a normal deprecation cycle, but I'm more flexible than
some.

>   - Do we have a formal definition of what bitSize means? E.g.,
> could/should a (finite) ByteString be made an instance of this?

I think bitSize is already defined as to mean the number of bits used
in the representation of the value.  There are no padding bits and it
does not depend on the value (so passing "undefined :: T" should work
for all instances).  This means ByteString could not be a reasonable
instance.  If, OTOH, we had reifyable type level numerics and a
ByteString-like type that encoded it's length in the type then this
could be an instance.

-The other Thomas

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Add hasBitSize to Data.Bits.Bits

Antoine Latter-2
In reply to this post by Thomas Schilling-2
On Sun, Jul 29, 2012 at 10:37 AM, Thomas Schilling
<[hidden email]> wrote:

> On 29 July 2012 15:37, Thomas DuBuisson <[hidden email]> wrote:
>>> Is 'bitSize' a useful function to use monomorphically? It seems a
>>> waste and irritating to have it return Maybe if I'm not using
>>> Integer.
>>
>> That is a great point.  Most my uses of 'bitSize' are monomorphic and
>> Maybe would just be silly.  OTOH, I'd be more than happy to fix up any
>> polymorphic code to include a new BitSize constraint.
>
> To make sure I understand this correctly:
>
> The current problem is that bitSize is a partial function *depending
> on the type* of its argument (currently it always returns _|_ for
> Integer, and is total for any other type). That does indeed seem like
> a Bad Idea.
>
> You propose to:
>
>   1. Remove "bitSize" from the Bits class.
>   2. Add a new class BitSize which only contains the "bitSize" method.
> Integer would not be an instance of this class.
>

The downside to this proposal is that the requester (Edward) actually
wants a function of type "a -> Maybe Int", so his polymorphic function
can handle both infinite bit-types and finite bit-types.

With the new class, Edward could write:

class BitTraversable i where
  traverseBits :: <sometype>

instance (BitSize i) => BitTraversable i where
  traverseBits = <something>

instance BitTraversable Integer where
  traverseBits = <something else>

Antoine

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Add hasBitSize to Data.Bits.Bits

Antoine Latter-2
On Sun, Jul 29, 2012 at 11:37 AM, Antoine Latter <[hidden email]> wrote:

>
> The downside to this proposal is that the requester (Edward) actually
> wants a function of type "a -> Maybe Int", so his polymorphic function
> can handle both infinite bit-types and finite bit-types.
>
> With the new class, Edward could write:
>
> class BitTraversable i where
>   traverseBits :: <sometype>
>
> instance (BitSize i) => BitTraversable i where
>   traverseBits = <something>
>
> instance BitTraversable Integer where
>   traverseBits = <something else>
>

I should add that this approach looks like it would require
OverlappingInstances.

Antoine

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Add hasBitSize to Data.Bits.Bits

Henning Thielemann
In reply to this post by Thomas Schilling-2

On Sun, 29 Jul 2012, Thomas Schilling wrote:

> On 29 July 2012 15:37, Thomas DuBuisson <[hidden email]> wrote:
>>
>> That is a great point.  Most my uses of 'bitSize' are monomorphic and
>> Maybe would just be silly.  OTOH, I'd be more than happy to fix up any
>> polymorphic code to include a new BitSize constraint.
>
> To make sure I understand this correctly:
>
> The current problem is that bitSize is a partial function *depending
> on the type* of its argument (currently it always returns _|_ for
> Integer, and is total for any other type). That does indeed seem like
> a Bad Idea.
>
> You propose to:
>
>  1. Remove "bitSize" from the Bits class.
>  2. Add a new class BitSize which only contains the "bitSize" method.
> Integer would not be an instance of this class.

+1

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Add hasBitSize to Data.Bits.Bits

Edward Kmett-2
In reply to this post by Antoine Latter-2


On Sun, Jul 29, 2012 at 12:38 PM, Antoine Latter <[hidden email]> wrote:
On Sun, Jul 29, 2012 at 11:37 AM, Antoine Latter <[hidden email]> wrote:
>
> The downside to this proposal is that the requester (Edward) actually
> wants a function of type "a -> Maybe Int", so his polymorphic function
> can handle both infinite bit-types and finite bit-types.
>
> With the new class, Edward could write:
>
> class BitTraversable i where
>   traverseBits :: <sometype>
>
> instance (BitSize i) => BitTraversable i where
>   traverseBits = <something>
>
> instance BitTraversable Integer where
>   traverseBits = <something else>
>

I should add that this approach looks like it would require
OverlappingInstances.

Correct. This is not a viable solution for the problem, also it precludes the existance of support for someone else's Natural number type, etc.

Every type that is currently an instance of Bits is either of a fixed size or potentially infinite.

Changing bitSize to return a Maybe a works. Making a separate BitSize class simply forces me to do exactly what I'm doing right now, which is ignore it and manually probe. 

I'm a strong -1 vote to any solution that splits BitSize out into a separate class.

-Edward

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Add hasBitSize to Data.Bits.Bits

Henning Thielemann

On Mon, 13 Aug 2012, Edward Kmett wrote:

> Correct. This is not a viable solution for the problem, also it precludes the existance of support for
> someone else's Natural number type, etc.
>
> Every type that is currently an instance of Bits is either of a fixed size or potentially infinite.
>
> Changing bitSize to return a Maybe a works. Making a separate BitSize class simply forces me to do exactly
> what I'm doing right now, which is ignore it and manually probe. 

How about two versions of 'bitSize' - one with Maybe return type in the
Bits class and one without Maybe in a FixedBitSize subclass?


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Add hasBitSize to Data.Bits.Bits

Edward Kmett-2
That would work perfectly.

Sent from my iPhone

On Aug 13, 2012, at 5:48 PM, Henning Thielemann <[hidden email]> wrote:

>
> On Mon, 13 Aug 2012, Edward Kmett wrote:
>
>> Correct. This is not a viable solution for the problem, also it precludes the existance of support for
>> someone else's Natural number type, etc.
>> Every type that is currently an instance of Bits is either of a fixed size or potentially infinite.
>> Changing bitSize to return a Maybe a works. Making a separate BitSize class simply forces me to do exactly
>> what I'm doing right now, which is ignore it and manually probe.
>
> How about two versions of 'bitSize' - one with Maybe return type in the Bits class and one without Maybe in a FixedBitSize subclass?
>

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Add hasBitSize to Data.Bits.Bits

Johan Tibell-2
In reply to this post by Henning Thielemann
On Mon, Aug 13, 2012 at 2:48 PM, Henning Thielemann
<[hidden email]> wrote:
> How about two versions of 'bitSize' - one with Maybe return type in the Bits
> class and one without Maybe in a FixedBitSize subclass?

Is this worth breaking existing users of bitSize over? If anything it
seems more worthwhile to throw out Integer from the Bits class and
declare Bits to be for fixed sized entities.

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Add hasBitSize to Data.Bits.Bits

Henning Thielemann

On Mon, 13 Aug 2012, Johan Tibell wrote:

> On Mon, Aug 13, 2012 at 2:48 PM, Henning Thielemann
> <[hidden email]> wrote:
>> How about two versions of 'bitSize' - one with Maybe return type in the Bits
>> class and one without Maybe in a FixedBitSize subclass?
>
> Is this worth breaking existing users of bitSize over?

If the method of 'FixedBitSize' is named 'bitSize' then only the type
signature will be affected (FixedBitSize constraint instead of Bits).
Although I don't know whether this is a good solution.

> If anything it seems more worthwhile to throw out Integer from the Bits
> class and declare Bits to be for fixed sized entities.

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Add hasBitSize to Data.Bits.Bits

Johan Tibell-2
On Mon, Aug 13, 2012 at 3:19 PM, Henning Thielemann
<[hidden email]> wrote:

>
> On Mon, 13 Aug 2012, Johan Tibell wrote:
>
>> On Mon, Aug 13, 2012 at 2:48 PM, Henning Thielemann
>> <[hidden email]> wrote:
>>>
>>> How about two versions of 'bitSize' - one with Maybe return type in the
>>> Bits
>>> class and one without Maybe in a FixedBitSize subclass?
>>
>>
>> Is this worth breaking existing users of bitSize over?
>
>
> If the method of 'FixedBitSize' is named 'bitSize' then only the type
> signature will be affected (FixedBitSize constraint instead of Bits).
> Although I don't know whether this is a good solution.

Imports will have to be modified as well if Bits keeps the name
'bitSize' for its method.

In general these kind of breakages has been very painful in the past.
Most libraries need to support the last two or three released versions
of GHC (and thus base) so breaking changes like this are likely to
result in lots of #ifdefs in client code to paper over the
differences. Perhaps I'm getting old and cranky but I more in the
never-break-anything camp than I used to be.

-- Johan

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Add hasBitSize to Data.Bits.Bits

Henning Thielemann

On Mon, 13 Aug 2012, Johan Tibell wrote:

> On Mon, Aug 13, 2012 at 3:19 PM, Henning Thielemann <[hidden email]> wrote:
>>
>> If the method of 'FixedBitSize' is named 'bitSize' then only the type
>> signature will be affected (FixedBitSize constraint instead of Bits).
>> Although I don't know whether this is a good solution.
>
> Imports will have to be modified as well if Bits keeps the name
> 'bitSize' for its method.
>
> In general these kind of breakages has been very painful in the past.
> Most libraries need to support the last two or three released versions
> of GHC (and thus base) so breaking changes like this are likely to
> result in lots of #ifdefs in client code to paper over the
> differences.

That's true. How about keeping 'bitSize' as it is, maybe deprecate it in
the future, add maybeBitSize to Bits class and add a new class
FixedBitSize with method fixedBitSize?

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
123