Monoid over XOR or XNOR, and Monoid lifted by Applicative.

[Edward Kmett]

In that same light, we're also missing packaged monoids for the bitwise
(.|.), (.&.), xor (and the non-existent xnor) from Data.Bits. Bool is an
instance of Bits. Extending this to these more general types you'd get:

newtype And a = And { getAnd :: a }
newtype Or a = Or { getOr :: a }
newtype Even a = Even { getEven :: a }
newtype Odd a = Odd { getOdd :: a }

Once things move to arbitrary bitwise operations, Even/Odd may not be the
best names, though they do perform "vertical" bitwise parity checks.

While I don't have a particularly strong preference about whether those
extra instances should live in Data.Monoid or Data.Bits, due to Monoid now
being in Prelude, users do import Data.Monoid unqualified in rather more
code than Bits. This would give me a slight preference to placing these in
Data.Bits, but if one or the other would create an import cycle in base, I
think it'd be fine to let that trump such a concern and force the placement.

-Edward

On Wed, May 2, 2018 at 10:31 AM, 박신환 <ndospark320 at naver.com> wrote:

> Logical XOR is associative, also is XNOR. And they both have an identity
> element.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20180505/3d0b3eb4/attachment.html>