Proposal: Remove Num superclass of Bits

Edward Kmett ekmett at
Sun Oct 16 03:16:05 CEST 2011

I'm with wren -1 on the overloaded boolean stuff, but definitely still +1 on
this proposal over all.

On Sat, Oct 15, 2011 at 9:00 PM, wren ng thornton <wren at> wrote:

> On 10/15/11 8:33 PM, Bas van Dijk wrote:
>> But an important question is: is it wise to treat booleans and bits
>> equally? Because this would allow something like:
>> {-# LANGUAGE RebindableSyntax #-}
>> foo = if 1 then 2 else 3
> Well, they're both Boolean algebras... But the big question is, or should
> be, what exactly are we trying to model with the Bits class? The current
> design is clearly aimed at modelling bitvectors, and just happens to support
> a few other things too. Given this initial design, it's not at all clear
> that it would be sensible to replace that with a model for Boolean algebras.
> Indeed, if I were trying to model Boolean algebras, I'd probably start with
> some classes for semilattices and then move up to complemented distributive
> lattices from there. This would set the ground for a better handling of
> partial orders and repairing the inconsistency of Float/Double's Ord
> instances. Unfortunately, it's liable to crash into the folks extending
> Monoid and the like, and it's not entirely clear how best to reconcile their
> interaction.
> Personally, I'm -1 for treating Bits like Bool in rebindable syntax. While
> some Bits instances could sensibly be treated as Booleans in conditionals,
> not all of them can. In particular, anything other than bivalent Boolean
> algebras is going to introduce ambiguity. If Bits can be Bools, it should be
> an opt-in system rather than extending if_then_else_ to incorporate all
> Boolean algebras in an unclear and ambiguous way.
> --
> Live well,
> ~wren
> ______________________________**_________________
> Libraries mailing list
> Libraries at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list