Proposol: make Data.Bits algebraic

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

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

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
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
wrote: Hello,
The current version of Data.Bits is non-algebraic, in so far as the Bits
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
class has 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
participants (3)
-
Carter Schonwald
-
Johnson-Freyd, Philip Alden
-
Zemyla