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

[David Feuer]

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