Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!munnari.oz.au!cs.mu.oz.au!ok
From: ok@cs.mu.oz.au (Richard O'Keefe)
Newsgroups: comp.lang.c
Subject: Re: ambiguous ?
Message-ID: <2493@munnari.oz.au>
Date: 23 Oct 89 05:57:02 GMT
References: <1989Oct21.071319.8839@utzoo.uucp> <14106@lanl.gov>
Sender: news@cs.mu.oz.au
Lines: 26

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.
In article <14106@lanl.gov>, jlg@lanl.gov (Jim Giles) writes:
> 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 lose a considerable
> number of opportunities to optimize.

C does not "suppress" the mathematical properties of conjunction and
disjunction.  It provides operators which _do_ have those properties,
and control flow operators which _don't_.  It is reasonable to say,
then, that the purpose of && and || is to force evaluation order,
because if you _don't_ want to force a particular evaluation order
you can use & and |.  Honesty compells me to admit that the two C
compilers I just checked on a 68020 don't actually do a good job of
optimising (i <= j) & (j <= k), largely because the 680x0 s<cc>
instructions generate a 0x00 or 0xFF *byte* result and these compilers
would much rather not generate an "and.b" so they do some pointless
conversion to long.  But there is no reason why a C compiler _couldn't_
generate good code for & and |.

If you want functions with guaranteed argument evaluation order, try
FORTH and PostScript.