Xref: utzoo comp.lang.c:11061 comp.lang.fortran:858
Path: utzoo!attcan!uunet!husc6!cca!g-rh
From: g-rh@cca.CCA.COM (Richard Harter)
Newsgroups: comp.lang.c,comp.lang.fortran
Subject: Re: Mathematical expression syntax (was: C vs. Fortran)
Message-ID: <30165@cca.CCA.COM>
Date: 1 Jul 88 14:30:57 GMT
References: <20506@beta.lanl.gov> <559@lanl.gov> <20509@beta.lanl.gov>
Reply-To: g-rh@CCA.CCA.COM.UUCP (Richard Harter)
Organization: Computer Corp. of America, Cambridge, MA
Lines: 29

In article <20509@beta.lanl.gov> jlg@beta.lanl.gov (Jim Giles) writes:

>The converse is also true.  Anyone who can defend x+=(p=foo(b)?++i:i--)
>should have no trouble with the arithmetic IF.  The arithmetic IF is
>obsolete and is only maintained for backwards compatibility.  I don't
>know anyone who uses it for new code.  The above C code is still
>considered _good_ code?

Ahem.  There is actually a good reason for the arithmetic IF, albeit not
in the style of fortran.  Any time you compare two items with an order
relationship you have three possible cases, 1st<2nd, ==, and 2nd>1st.
The three way comparison is a very natural and common situation.  The
problem with the arithmetic IF is the use of statement numbers.  In a
more modern style one would use three blocks, e.g.

compare(x,y) {
	lt: stuff if x less than y
	eq: stuff if they are equal
	gt: stuff if x greater than y
	}

with ge, le, and ne covering the combined cases.  The point is that the
standard boolean IF is a two way switch; any method for converting a
three way switch into two switches has its minuses.
-- 

In the fields of Hell where the grass grows high
Are the graves of dreams allowed to die.
	Richard Harter, SMDS  Inc.