[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: MURRAY%umass-cs.csnet@CSNET-RELAY.ARPA, common-lisp@SU-AI.ARPA
- Subject: Comments
- From: Guy Steele <gls@THINK-AQUINAS.ARPA>
- Date: Thu, 26 Dec 85 13:28 EST
- Cc: gls@THINK-AQUINAS.ARPA
- In-reply-to: The message of 22 Dec 85 17:15-EST from MURRAY%umass-cs.csnet@CSNET-RELAY.ARPA
Date: Sun, 22 Dec 85 17:15 EST
I think the discussion about whether there should be an XOR
function is very much off the mark. I think the criterion for
including any new operator in the language should be one of
1) It is not possible to write it in Common Lisp.
2) It can be implemented MUCH more
efficiently in an implemention dependant way.
3) It requires a lot of programming effort (and is generally useful).
There should be a fourth criterion:
4) It is so useful that many individual users keep reinventing it,
and therefore it is deserving of standardization.
PUSH and POP fall into this category, for example. On the other hand, I
will not argue that XOR does fall into this category, as all the
reent evidence on the mailing list indicates otherwise.
Several others have also pointed out the potential ambiguity in extending
XOR to more than two arguments: is it "an odd number true", "exactly one
true", or "all but one true" (the latter being unlikely given the name,
but nevertheless a consistent extension)? The main reason for choosing
"an odd number true" is that that definition is associative, whereas the
other choices are not. If XOR were to be added to the language (and I will
not argue strongly that it should be), I would suggest making it a function
(not a special form) of exactly two arguments (to avoid the ambiguity).
I do not find convincing the argument against XOR on the grounds that
it cannot terminate its execution early the way AND and OR do. After all,
NOT is usually in the same bag as AND and OR, and it is not a special form.
I would say that XOR is more like NOT than like AND and OR.