Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site iscuva.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!tektronix!reed!iscuva!jimc
From: jimc@iscuva.UUCP (Jim Cathey)
Newsgroups: net.lang.c
Subject: Re: What should be added to C
Message-ID: <236@iscuva.UUCP>
Date: Tue, 27-May-86 16:39:35 EDT
Article-I.D.: iscuva.236
Posted: Tue May 27 16:39:35 1986
Date-Received: Fri, 30-May-86 07:51:43 EDT
References: <590@brl-smoke.ARPA> <3570@nsc.UUCP> <1462@mmintl.UUCP> <3414@ut-ngp.UUCP>
Reply-To: jimc@iscuva.UUCP (Jim Cathey)
Organization: ISC Systems Corporation, Spokane, Wa.
Lines: 71


I got messed up in figuring out who wrote what here, and had to dump the
names, but that is not the point.

>> 
>> o := as a synonym for =.  Compilers could have an option to permit := only.
>> 
>
>Why?  "Since assignment is about twice as frequent as equality testing
>in typical C programs, it's appropriate that the operator be half as long."
>K&R, p. 17.  Allowing := as a synonym is OK, if you prefer that operator,
>but why would you want to make it manditory?

YES, I HATE `:='.  While I admit it is easy to read, the fact that on all the
keyboards I've used except the IBM keypunch, the two symbols are in different
cases and very awkward to type...and yes, I do know about smart editors!

>> I do not support the following:
>> 
>> o ^^ for logical exclusive or.  Unlike the other "short-circuit" forms (&&
>> and ||), this doesn't save any execution -- both operands must be evaluated.

YES!

>So what if they both have to be evaluated?  If you need to use some
>kludge to get ^^ (like !a != !b), you will still wind up evaluating both
>operands.  That's just the way XOR works.  Just because it requires more
>work is no reason to exclude it from the language.

I think this misses the point.  The short-circuit versions of AND and OR
are just that - SHORT CIRCUIT versions!  These are intended to be used
in place of the regular AND and OR when appropriate, to avoid much extra
if () testing.  I think K&R makes this clear.  I do admit that you can
almost always use the short circuit versions in conditionals even when not
required, for efficiency's sake.  Just gotta watch the side-effects and
parentheses!

	if (one_expr | the_other_expr) then_barfo;
	if (one_expr & the_other_expr) then_barfo;

will often work just as well as:

	if (one_expr || the_other_expr) then_barfo;
	if (one_expr && the_other_expr) then_barfo;

provided that the two expressions evaluate to whatever a boolean int is
locally (1 or -1).  {BTW I usually use set_me_true = (1 == 1)}

For XOR, where there can be no concept of a short circuit, one should
be using the regular ^ operator instead.  Something like:

	if (one_expr ^ the_other_expr) then_barfo;

given the above restrictions.  A ^^ operator is syntactically null given
the theme expressed by AND and OR.  Of course, if the expressions being
tested are not 'boolean', then the single-character operators can fail
where the double-character operators will succeed.  If you are using
the double-character operators as boolean-normalizing flavors of the
single-character operators, then I can see the point in wanting a ^^.
This, to me, is not what was intended when && and || were created.

-- 

+----------------+
! II      CCCCCC !  Jim Cathey
! II  SSSSCC     !  ISC Systems Corp.
! II      CC     !  Spokane, WA
! IISSSS  CC     !  UUCP: ihnp4!tektronix!reed!iscuva!jimc
! II      CCCCCC !  (509)927-5757
+----------------+
			"With excitement like this, who is needing enemas?"