Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!hc!lanl!jlg
From: jlg@lanl.gov (Jim Giles)
Newsgroups: comp.lang.fortran
Subject: Re: Fortran versus C for numerical analysis
Message-ID: <3417@lanl.gov>
Date: 10 Sep 88 22:21:57 GMT
References: <408@marob.MASA.COM>
Organization: Los Alamos National Laboratory
Lines: 61

From article <408@marob.MASA.COM>, by samperi@marob.MASA.COM (Dominick Samperi):
> In article <3349@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>>the rules of C (there are rules in C?) do.  The problem with C is that
>>it provides _no_ way to force a given order of expression evaluation
> 
> But you criticized C (ANSI C) for forcing a left-to-right evaluation order
> in expressions like a+b+c+d in a previous posting. The beauty of C stems
> [...
I have never criticized C (either ANSI or K&R) for forcing strict left
to right ordering.  Neither makes that requirement.  I the most recent
version of the ANSI standard _does_ make that constraint, I'm opposed!
Allowing _no_ optimization is as bad as not constraining optimization.
There should be a middle ground which allows the compiler to optimize
in most cases but allows the user to enforce a particular order in those
cases where it's important to do so.

> from the mathematical consistency of its rules; the new (strict)

What consistency?  There are deliberately ambiguous features in C.  Not
just in expression ordering, but in assignment ordering.  For example:
what is the value of i after the expression i=f(i++)?  Both ANSI and K&R
say this is undefined but _not_ illegal.  And this is the language you
claim is consistent?

> I'm sure that the new FORTRAN standard will address many of the shortcommings
> [...]
> specs. (the simple operators associate left-to-right, except for **, which
> associates right-to-left, but forget this because the compiler can do
> what it pleases for optimization...), programming guidelines made part
> of the language spec., etc. 

Exponentiation is _not_ associative so I don't know what you're telling
me about the 'compiler can do what it pleases'.  Operators which _are_
associative may be optimized using this fact as long as the integrity
of parenthesis is observed.  This has been around (and _well_ understood)
for much longer than C has even existed.  It's only C programmers who
complain about this rule, many even claim not to understand it.  Most
other programming languages follow the same rule as Fortran.  It is a
good rule.  C has no such rule.  By the way, just out of curiosity,
what 'programming guidelines' are part of the Fortran language spec?
I've got the standard right here and I can't find any.

> Unfortunately, last I heard was that this new FORTRAN standard is not likely to
> appear for a long time, due to the inability of the committee to
> agree on anything.

The same might be said of the C committee.  C is out for its _third_
public review (Fortran has only had one so far).  And so far the C
committee hasn't addressed many of the shortcommings of the K&R version
(like deliberate ambiguities in the semantics, conflicting operator
precidence rules (the worst are the unary prefix and postfix operators
some of which have high precidence and some of which have lower precidence),
arcane declaration syntax, etc.).  None of this even mentions the unreadable
terse syntax, the lack of even the _concept_ of an array (the array syntax
is instantly turned into pointers - there is no semantic concept of arrays),
and no floating-point arithmetic (ANSI will supposedly introduce it, but
C has previously been _all_ double precision), the lack of complex data
type (macros are inherently slower and less optimizable, other patches
for complex are even less attractive), etc..

J. Giles
Los Alamos