Proposal: Data.Bool.implies

Edward Kmett ekmett at
Tue Jan 26 15:23:00 UTC 2016

I don't care one way or the other about the creation of implies, I'm happy
to bow to popular opinion either way.

I do care about changing the strictness of the comparisons in Ord Bool,
however, and that would require a rather massive survey of what breaks, and
what gets slower -- one that we simply haven't done -- before I'd even
start to be comfortable with it.


On Mon, Jan 25, 2016 at 12:27 PM, wren romano <wren at>

> -1 for changing the Ord Bool instance, due to the likelihood of subtle
> bugs and regressions.
> -1 for using the name (==>) due to conflict with QuickCheck, Smallcheck,
> etc.
> Ambivalent about adding an implication operator distinct from (<=),
> mainly because I haven't needed it myself. IMO, the ordering on Bool
> should be defined so that it coincides with implication, thanks to the
> relationship to Boolean/Heyting algebras— which the current Ord
> instance already does. Though I do agree that if implication is given
> its own name then it ought to be lazy in the second argument, whereas
> it's not clear that (<=) should share that strictness/laziness.
> Personally, were I to add something like implication, I'd define it
> via a type class so that we can unify the things called (==>) in
> various testing frameworks. Of course, doing this appropriately would
> mean making a decent hierarchy of type classes for order/lattice
> theory. But given as we don't have one of those yet, I'd do it in a
> separate package so it could be played around with until everything
> fits together nicely, and then aim to get it blessed into HP rather
> than changing base.
> --
> Live well,
> ~wren
> _______________________________________________
> Libraries mailing list
> Libraries at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list