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
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