|
Prev: Lisp and Web Programming
Next: Koch figures
From: Louis Theran on 13 Jul 2005 21:01 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 14 Jul 2005 01:37 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 14 Jul 2005 02:26 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 14 Jul 2005 02:36 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 14 Jul 2005 02:40
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? |