XOR

[Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>]

    Date: Mon, 16 Dec 85 16:44 EST
    From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
    Subject: XOR
    To: Guy Steele <gls@THINK-AQUINAS.ARPA>, Moon@SCRC-STONY-BROOK.ARPA,
	Steele@THINK-AQUINAS.ARPA
    cc: Common-Lisp@SU-AI.ARPA
    In-Reply-To: <851216130507.6.GLS@THINK-JEHOSEPHAT.ARPA>
    Message-ID: <851216164401.5.DCP@NEPONSET.SCRC.Symbolics.COM>

	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
open...

 * 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.