Discussion: Change the specification of rotateL for non-finite Bits, or move rotations to FiniteBits

David Feuer david.feuer at gmail.com
Mon Sep 29 19:54:50 UTC 2014

No particular use case. Just trying to look at where the boundaries
lie. I think rejecting such things is an argument for putting
rotations in `FiniteBits`, though.

On Mon, Sep 29, 2014 at 3:10 PM, John Lato <jwlato at gmail.com> wrote:
> Do you have a use case for this instance? I don't think I would ever want
> it. Also I think the behavior is too unspecified, and trying to specify it
> more precisely will inevitably lead to a much less useful instance. In this
> instance I might prefer we focus on problems we have already rather make new
> ones.
> Also +1 for rotate acting like shift for infinite types, for the reasons
> Milan gave.
> John L.
> On Sep 29, 2014 11:28 AM, "David Feuer" <david.feuer at gmail.com> wrote:
>> Thinking about this some more, I ran into something else to chew on.
>> It would seem to make a certain amount of sense to have
>> instance (Bits b) => Bits (Seq b)
>> with .&., .|., and xor defined using a zero-prepending zipWith variant.
>> but there are a few challenges relating to size. Specifically:
>> 1. The specification indicates that finiteBitSize and bitSizeMaybe are
>> supposed to return a result based only on the type of their argument.
>> Clearly, that will not work for this.
>> 2. There is no obviously correct size to use for zeroBits and bit.
>> One approach, of course, is to define something wonky like
>> newtype SeqN (n::Nat) a = SeqN (Seq a)
>> and then use
>> instance (Bits b) => Bits (SeqN n b)
>> but that gives a different, more limited type than one might expect.
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries

More information about the Libraries mailing list