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 <ben.franksen@online.de> wrote:
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