Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!attctc!kcdev!pars!cpsolv!rhg
From: rhg@cpsolv.UUCP (Richard H. Gumpertz)
Newsgroups: comp.lang.c
Subject: Re: C history question
Summary: guesses concerning the lack of ^^ and ||= and &&=
Keywords: C design, XOR
Message-ID: <174@cpsolv.UUCP>
Date: 15 Sep 89 14:34:56 GMT
References: <575@calmasd.Prime.COM> <1687@sunset.MATH.UCLA.EDU>
Reply-To: rhg@cpsolv.uucp (Richard H. Gumpertz)
Organization: Computer Problem Solving, Leawood, Kansas
Lines: 40

The && and || operators differ from the & and | operators in two respects:
    1) they do NOT perform bitwise operations; 4 && 2 is 1 while 4 & 2 is 0.
    2) they are guaranteed to perform short-circuited evalauations: the
       right-hand operand will NOT be evaluated if the left-hand operand
       determines the value of the expression.
An ^^ operator would maintain the first property of not being bitwise which
would be usesful for non 0/1 booleans; on the other hand no short-circuit
evaluation is possible with XOR because BOTH operands must always be evaluated. 

&& and || also have straightfoward implementations in control-flow (e.g. inside
an IF) contexts; ^^ is not as straightforward in most architectures.  Most
compilers would have to implement X ^^ Y as (X != 0) ^ (Y != 0) or as
X ? (Y == 0) : (Y != 0) or such.

Might the lack of short-circuiting and the lack of any code advantage over the
equivalents given above caused K&R to decide the ^^ operator was not worthwhile?

As for &&=, ||=, and ^^=, might the lack of trivial implementation (few
if any architectures directly implement the non-bitwise booleans; only flow-
contexts allow "better" code to be produced for && and ||; &&= and ||= are
by definition not flow contexts!) have affected K&R similarly?  They might
have reasoned that X = (X != 0) & (Y != 0) or X = (X != 0) && (Y != 0) will
generate code as good as X &&= Y and so left them out.

I hate resorting to implementation arguments when discussing the design of a
language, but after all C does very much reflect its history as an
implementation language with few "expensive-to-implement" operations hidden
behind seemingly simple operators.

As long as we are discussing missing "assignment" operators, you might ponder
the lack of unary assignment operators.  Why should I have to say X = -X or
X = ~X?  Why not have unary assignment operators (ala ++ and --) for negation
and complement?  I suppose a new syntax would have to be invented, but it might
be useful at times.  Remember that mentioning X only once guarantees that its
side-effects, if any, will happen only once!

Maybe K or R would care to chime in?

		Richard H. Gumpertz             (913) 642-1777
		...uunet!amgraf!cpsolv!rhg