Re: type class Boolean

I imagine you'd want (&&) and (||) to live in a Lattice class, `bottom` and `top` in `BoundedBelow` and `BoundedAbove`, respectively, and `not` in a `Boolean` one. The relationship between Lattice, JoinSemilattice, and MeetSemilattice is unfortunately awkward (much like that between Ring, AbelianGroup, and Monoid), but mumble mumble something. On Mon, Dec 21, 2020 at 6:32 PM Tikhon Jelvis wrote:

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

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries