Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!purdue!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.lang.c
Subject: Re: ambiguous ?
Message-ID: <11388@smoke.BRL.MIL>
Date: 23 Oct 89 14:55:05 GMT
References: <1989Oct21.071319.8839@utzoo.uucp> <14106@lanl.gov>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 36

In article <14106@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>From article <1989Oct21.071319.8839@utzoo.uucp>, by henry@utzoo.uucp (Henry Spencer):
>> the whole purpose of && and || is to force
>> conditional evaluation, and hence evaluation order.
>No, the effect these operators have on evaluation is only part of their
>"whole purpose".  The also happen to be infix operators which invoke
>boolean functions of two arguments.  The functions are, mathematically,
>commutative and associative.  It is not, necessarily, a good idea for
>the language to supress these characteristics - you loose a considerable
>number of opportunities to optimize.  Some studies I've seen in the
>literature recommend that the boolean operators should _not_ force
>evaluation order.  I have no particular opinion on this issue except
>that I am not satisfied with the loss optimization, but I wouldn't be
>satisfied without a way to force order either - can't have both (or
>can you?  I know of an experimental language with both).

Obviously Henry knows that they are Boolean operators.
He just as obviously meant that the whole purpose of the
short-circuit specification for these operators is to etc. etc.

The mathematical formalisms to which you allude do not deal with
side effects, which is the only thing that makes evaluation order
an issue.  In spite of appearances, general-purpose programming
languages do NOT implement mathematics, so arguments about how
mathematicians do things are usually not helpful.

In the total context of C as an integrated programming language,
the short-circuit nature of the && and || operators is very
valuable.  That is undoubtedly evident to any observant experienced
C programmer.

In any case, there is no point in arguing about it here.  These
are fundamental attributes of C that are not going to be changed.
One can learn to exploit them (or, in your case, perhaps, simply
to deal with them), but discussion about whether what is, should
be, are a waste of time.