From: Louis Theran on
Frank Buss wrote:
> Frank Buss wrote:

> I forgot the index, so some standard loop magic:

If you are already using loop, save typing:

(defun xor (&rest args)
(loop for (a . d) on args
for i from 0
until a
finally (return (and (every 'null d) (values a i)))))

Normally, with the name xor, I would expect something like:

(defun xor (&rest args)
(oddp (count nil args :key 'null)))

^L

From: Kent M Pitman on
hannah(a)schlund.de (Hannah Schroeter) writes:

> Hello!
>
> Russell McManus <russell_mcmanus(a)yahoo.com> wrote:
> >[...]
>
> >I think this works:
>
> >(defmacro xor (v1 v2)
> > `(not (eq (not ,v1) (not ,v2))))
>
> Use macros only if functions don't work.
>
> (defun xor (v1 v2)
> (not (eq (not v1) (not v2))))

Incidentally, as a matter of history, after the publication of the
first CLTL in 1984, there was a meeting in 1986 in Monterrey CA to
talk about how to proceed. Steel brought a list of things he thought
were obvious and non-controversial that he wanted to change. Of
the people attending (many of whom were not original designers of
CLTL but new people who had read it and started to use the language
or make implementations and felt they should have a say in how it
moved forward), little concensus was to be had other than that a
lot of people objected to a lot of the things on the list as non-obvious.

One of the items on that list was the addition of xor. As I recall
what made it controversial was precisely this question of whether it
should be a macro or special form (for consistency with AND and OR) or
a function (because it somewhat accidentally is able to be, as an
accident of how it is computed). Of the pre-defined operators by
CLTL, I believe PROG1 is the only one that could have been implemented
as a normal function, but is defined not to be...

Anyway, I just wanted to raise the issue that this is a well-known
issue of somewhat historical nature.

You can probably find out how the Monterrey meeting turned out in Google.
But in short, it's spectacular lack of ability to get consensus led
to a decision to start ANSI subcommittee X3J13...
From: Frank Buss on
Christophe Rhodes wrote:

> Why is this nice?

because this is what xor means: the output is true, if exactly one of the
input is true. I think this could be used more often as the other
interpretation with counting the number of nils and checking for odd.

--
Frank BuĂ˝, fb(a)frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
From: Christophe Rhodes on
Frank Buss <fb(a)frank-buss.de> writes:

> Christophe Rhodes wrote:
>
>> Why is this nice?
>
> because this is what xor means: the output is true, if exactly one of the
> input is true.

That is not what multiple argument xor means.

> I think this could be used more often as the other interpretation
> with counting the number of nils and checking for odd.

If you had any evidence for this, this might be a good reason, apart
from the fact that this interpretation is counter to the mathematical
definition.

Christophe
From: Christopher C. Stacy on
Frank Buss <fb(a)frank-buss.de> writes:

> Christophe Rhodes wrote:
>
> > Why is this nice?
>
> because this is what xor means: the output is true, if exactly one of the
> input is true. I think this could be used more often as the other
> interpretation with counting the number of nils and checking for odd.

XOR is associative, which is why the n-ary (ODDP (COUNT NIL ..))
version is consistent with the two-arg version. And since the
n-ary version doesn't cons, why wouldn't it be better?


First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9
Prev: Lisp and Web Programming
Next: Koch figures