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