Yeah. Agreed It sounds like, in principle, Philip should circle back with how to add some additional type classes and spell those out BUT: currently we don’t have a good mechanism actually implemented in Haskell / ghc for upgrading a type class hierarchy seamlessly with new type classes at the middle or top of a type class hierarchy. This raises the bar for experiments and api changes because of the migration / breakage If only we actually had one of those super class mechanisms implemented and merged into ghc , a lot of cool stuff could happen 🕵️♂️🤔 On Mon, Mar 11, 2019 at 11:58 PM Zemyla <zemyla@gmail.com> wrote:
Bits can't be algebraic, because the testBit function exists. Anything where finiteBitsMaybe returns Just (a number) can be tested for equality, and even if it returns Nothing, it can still be tested for inequality, or equality up to a certain index.
On Mon, Mar 11, 2019 at 4:49 PM Johnson-Freyd, Philip Alden via Libraries <libraries@haskell.org> wrote:
Hello,
The current version of Data.Bits is non-algebraic, in so far as the Bits
class has
1. a superclass constraint on `Eq` 2. operations `testBit` and `isSigned` which return `Bool`.
This is quite annoying, as myriad potential uses of the Bits class cover types for which these concrete observations are not possible. It leads to comments like the following in SBV:
-- | This instance is only defined so that we can define an instance for
-- 'Data.Bits.Bits'. '==' and '/=' simply throw an error. Use
-- 'Data.SBV.EqSymbolic' instead.
We had this same issue for `Num` for years, until it eventually got fixed. And it would be nice to fix the situation for `Bits` as well.
There are other aspects of the Bits API which are pretty clunky, but this is the one that is often a show stopper.
Philip
_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries