As others observed, "one" is only useful for the "bit" method default, and might be meaningless for an "instance () Bits" (whereas the rest of the class makes sense for () as a zero-bit instance, albeit a use doesn't come to mind). Or, similarly to (), a bit-vector which contains its length statically in its type: it would be simpler if length zero was just as valid as any other length. And it would be a bit strange to define 'one' as a value equal to 'zero'.
It isn't entirely meaningless it is just out of range. It is perfectly well defined for me to set the 200th bit of a 64 bit integer, it just doesn't do anything. ;) Similarly setting the 1 bit of () would result in (), since there are no bits to set.
But proposed member 'zero' is plain and simply "all bits zero". I can imagine users of Bits using that method, too.
(Side note: are there other classes that want to call things zero? e.g. there is mzero in MonadPlus. Bits is designed to import unqualified easily. Hoogle doesn't find anything currently named 'zero', so it may be fine.)
'zero' would break quite a few packages of mine, as 'Plus' in semigroupoids uses the name.
However, 'algebra' already has to import 90% of what it imports qualified anyways because it doesn't go out of its way to avoid prelude names. =) I'm willing to put in the effort to clean up those packages, and their 20 or so dependents simply because 'zero' does more naturally belong in something either numeric or bit-like, and we're far more likely to make meaningful progress on this front as opposed to progress on a usable numerical tower in my life time.
True enough. I would be somewhat concerned that we'd need to make sure it constant folded away to an efficient definition though.