[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Date: Mon, 16 Dec 85 16:44 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
To: Guy Steele <gls@THINK-AQUINAS.ARPA>, Moon@SCRC-STONY-BROOK.ARPA,
Date: Mon, 16 Dec 85 13:05 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Date: Sun, 15 Dec 85 16:35 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
The XOR function in your list of suggested language improvements
handed out last week was intended to be a joke, wasn't it? I assumed
it was, but other people on the mailing list are taking it seriously,
so I'm asking for clarification.
Of all the functions not in Common Lisp that I use day-to-day on my
3600, this is the one I use most frequently. I admit that I have been,
among other things, constructing logic models of various kinds.
However, I also find it useful in random COND clauses. Maybe the rest
of you will decide it is not useful, but in any case it is not a joke.
One argument I have heard against XOR is that, unlike AND and OR, it
must evaluate all of its forms.
Actually, that doesn't bother me. All three share the property that they evaluate
forms left to right until they have enough information to decide. The fact that
"enough information" is available early for AND and OR shouldn't be held against
XOR, which has other great properties to offer in exchange.
Of course, MLB once sent an amusing thing describing an XOR that returns
the right answer but somehow knows what the forms evaluate to so it can
stop early after the things it doesn't know a priori !-}
(:- Sure. eg, (WITHOUT-INTERRUPTS (XOR (FOO) (NOT (CAR X)) (CAR X))) :-)
On the more serious side, if we did introduce XOR, people might eventually
want reasonable answers to the following related issues, which would be left
* Why is OR not called IOR? (Or, why is LOGIOR not called LOGOR)
* Why aren't there special forms called NAND, NOR, CLR, SET(!), EQV,
ORC1, ANDC2, ... which do the other logical operations. If there were,
such forms (whatever they were named), some would have very peculiar
rules about when evaluation could be allowed to stop, and I'm not sure
if I'd want to have to learn them.
Certainly I've had a lot more use for NAND and NOR than for XOR.
A possibly reasonable alternative proposal might be to introduce a full set of
functional (ie, not special form) versions of all these operators. That way, we'd
simulataneously solve the problem that AND and OR cannot be applied (by providing
functions that could be). eg, just as a straw man I'll propose *AND, *IOR, *XOR,
*CLR, *SET, *EQV, *ORC1, ... Such functions could be known the the compiler and
interestingly optimized in predicate positions without needing to be special forms.
Also, (MAPCAR #'*AND (FOO)) or (APPLY #'*XOR (BAR)) would be possible.
- From: Guy Steele <gls@THINK-AQUINAS.ARPA>
- From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>