<div dir="ltr"><div>For me, the most useful kind of instance would be symbolic booleans like SBV's SBool type.</div><div><br></div><div>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!</div><div><br></div><div>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).</div><div><br></div><div>I don't think all of this belongs in base, but making booleans and boolean operators more polymorphic would definitely be useful.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Dec 21, 2020 at 3:21 PM Ben Franksen <<a href="mailto:ben.franksen@online.de">ben.franksen@online.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Am 21.12.20 um 19:54 schrieb Tom Ellis:<br>
> I think it's worth seeing more instances. As it is I don't understand<br>
> in what situations one would use these polymorphically and therefore<br>
> why `liftA2 (&&)`, `fmap not`, `pure True` and friends wouldn't<br>
> suffice.<br>
<br>
As with all overloading it's partly a matter of convenience. For<br>
instance you can't use 'liftA2 (&&)' as an operator. And your list of<br>
alternatives above demonstrates that one has to remember which lifting<br>
operator (pure, fmap, liftA2) to use, depending on arity.<br>
<br>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div>