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@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@haskell.org
http://www.haskell.org/mailman/listinfo/libraries