[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 7 logical-xor implementations in source tree

From: Mattias Engdegård
Subject: Re: 7 logical-xor implementations in source tree
Date: Thu, 25 Jul 2019 14:07:00 +0200

25 juli 2019 kl. 01.44 skrev Basil L. Contovounesios <address@hidden>:

> Stefan Monnier <address@hidden> writes:

>> - The name is too much like "equal/eq/eql": we need something much
>>  more explicit to avoid adding to the already existing confusion.
>>  I'd go with something like `bool-equal`.

bool-equal, bool-equiv, bool=, bool-eq are all fine as far as I'm concerned. 
`xnor' and `nxor', not so much.
Racket has `boolean=?', but presumably it only copes with #t/#f.
I'll be using `equiv' as placeholder below for brevity.

>> - The fact that it's not a function is a definite downside.
> Sure, though I'm interested to hear arguments to the contrary.

Small catalogue of arguments:

For a dyadic function, defsubst, or define-inline: mirrors the other 
equivalence predicates. Simplicity. Can be used in HOFs. Most common case.

For a variadic macro: short-circuits, like `and' and `or'. Dramatically 
simplifies use with 3 or more arguments.

For macro and define-inline: Fast; no abstraction penalty. Since conditions are 
boolean expressions themselves, may benefit from bytecode optimisations.

Against macro and define-inline: static byte-code size increase if arguments 
are complex expressions, since some of them will be expanded twice.

For and against defsubst: compromise between space and size; slightly slower 
and sometimes smaller than a macro.

>> - There's no use for it, currently.  If we can't find any use for it,
>>  I'm not sure it deserves to be in subr.el.

It's hard to say how many times either of the operators would have been used in 
the past had they being known, since there are many ways of open-coding the 
logic depending on the circumstances. (Examples from a simple pattern search at 
the end.)

>>  Actual/potential uses of it might also help figure out if having it as
>>  a function would be beneficial/useful and whether the detail about
>>  which non-nil value is returned is important and whether supporting
>>  more than 2 args is important.

I see little point in having xor but not equiv, but agree with this argument.

Hydrazine on the fire: `implies' is occasionally useful, especially in 
assertions. (Dijkstra would have liked it.)

Attachment: xor-equiv.log
Description: Binary data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]