On Jul 13, 2014 5:35 PM, "John Meacham" <john@repetae.net> wrote:
> Infinite bit sets I guess, I don't think it is that unreasonable to
> exist, were it not for that pesky bitSize.

No, that use *is* unreasonable. Infinite bitsets are just optimized unboxed expandable Boolean vectors, and it makes more sense to have one type that fills with False and another that fills with True than a notion that a bitset is "signed". IntN and WordN are special for two reasons: 1. Their sizes are especially fast. 2. They are numbers, and those bitwise operations can do some pretty cool things fast—the specific thing that I was looking at just now was a Java implementation of isSquare that maaartinus wrote on StackOverflow that uses a masked shift to index into a (logical) bitvector by the six low-order bits of a (logical) integer to see if those bits can be the low-order bits of a perfect square. When I went to do that in Haskell, I ran into all sorts of unpleasant limitations of Data.Bits and some very odd types in Data.Bits.Extras.

>
> FiniteBits and that deprecation are GHC specific. Though, it would
> make sense to port to jhc, it's fairly annoying for portable code to
> rely on ad-hoc changes like this.
>
> Looks like some work went into removing the Num superclass in ghc's
> base. Hmm... I think type class aliases are needed to actually make it
> backwards compatible though. Since bit is a primitive, you can get
> zero from the somewhat awkward 'clearBit 0 (bit 0)' and one from 'bit
> 1' and -1 from complement zero so the defaults that were dropped can
> be added back in using those.
>
>     John
> --
> John Meacham - http://notanumber.net/