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

[Edward Kmett]

Seq Bool and [Bool] aren't really correct Bits instances, let alone Bits a
=> Bits (Seq a) (the latter really only even starts to make sense for
FiniteBits a => Bits (Seq a), because you have to enumerate bits.

I also think defining such SeqN types (which _are_ legal) should really be
left up to the end user if they want them.

There are lots of points in the design space (Do you trim excess 0-bit only
entries from on the right? Leave them? etc.) it involves messy types, and
there is little to be gained by standardizing on one of them.

We don't have to include everything someone may someday want in base.

-Edward

On Mon, Sep 29, 2014 at 2:28 PM, 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140929/6b66b8e1/attachment.html>