For me, the most useful kind of instance would be symbolic booleans like
SBV's SBool type.
A real bonus would be making if-then-else polymorphic as well—although that
doesn't really fit with the lattice abstraction. I know we can do that with
RebindableSyntax, but that is a *heavyweight* extension to enable!
Breaking boolean behavior up into a few different classes would work for
this application. Boolean algebras for and/not/etc, Conditional for
ifThenElse and maybe even Boolish or something for True and False pattern
synonyms (or just true and false constants).
I don't think all of this belongs in base, but making booleans and boolean
operators more polymorphic would definitely be useful.
On Mon, Dec 21, 2020 at 3:21 PM Ben Franksen
Am 21.12.20 um 19:54 schrieb Tom Ellis:
I think it's worth seeing more instances. As it is I don't understand in what situations one would use these polymorphically and therefore why `liftA2 (&&)`, `fmap not`, `pure True` and friends wouldn't suffice.
As with all overloading it's partly a matter of convenience. For instance you can't use 'liftA2 (&&)' as an operator. And your list of alternatives above demonstrates that one has to remember which lifting operator (pure, fmap, liftA2) to use, depending on arity.
_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries