Re: 7 logical-xor implementations in source tree

[Mattias Engdegård]

31 juli 2019 kl. 22.22 skrev Basil L. Contovounesios <address@hidden>:
> 
> Stefan Monnier <address@hidden> writes:
> 
>> I vote to define either `bool-equal` or `xor` (and this "or" is mutually
>> exclusive ;-), in either case taking exactly 2 arguments (while those
>> functions can be generalized to more, it's far from clear that it's
>> worth the trouble.  After all `equal` still only takes 2 args).
>> 
>> Then replace the various uses of <foo>-xor with calls to this
>> new function.
> 
> +1.
> 
> If I had to pick one or the other, I would go with xor purely because it
> is the one that has been copied several times.  But I am also perfectly
> happy with bool-equal, especially if it is the historically/classically
> preferred function.

2 args is a reasonable simplification for both operators, and it allows `equiv' 
to be passed to HOFs that expect an equivalence relation. I haven't found much 
evidence for the need of an `equiv' of 3 or more operands either.

I'd favour `equiv' over `xor' but don't think we should be forced to make a 
hard choice: while each can be expressed as the inverse of the other, they are 
used with different intents ('exactly one' vs. 'same truth').

Regarding naming, I'd prefer equiv to bool-equiv to bool-equal, on the grounds 
that 'equivalence' is the most common way to describe the relation, well-known 
far outside specialised fields of logic and mathematics. `bool-equal' suggests 
either equality qua boolean or of booleanp values -- slightly ambiguous.

Attached is Basil's patch modified for a 2-arg `equiv' function, just as a 
reference point (and because code walks).

0001-Add-conditional-operators-xor-and-equiv-to-subr.el.patch
Description: Binary data