Xref: utzoo comp.lang.c:11071 comp.lang.fortran:863
Path: utzoo!attcan!uunet!husc6!bloom-beacon!tut.cis.ohio-state.edu!mailrus!ames!hc!lanl!beta!jlg
From: jlg@beta.lanl.gov (Jim Giles)
Newsgroups: comp.lang.c,comp.lang.fortran
Subject: Expression syntax in programming languages.
Keywords: C FORTRAN exponentiation
Message-ID: <20520@beta.lanl.gov>
Date: 1 Jul 88 16:58:54 GMT
References: <3136@phoenix.Princeton.EDU> <19633@watmath.waterloo.edu> <5174@ihlpf.ATT.COM>
Organization: Los Alamos National Laboratory
Lines: 59

In article <5174@ihlpf.ATT.COM>, nevin1@ihlpf.ATT.COM (00704a-Liber) writes:
> Since when does 'x = x + 1' resemble anything besides an obviously false
> statement in mathematics??  Also, since many of us use C for tasks other
> than number crunching, does this mean that we should have NO desire for a
> programming language to resemble mathematics?  Your reasoning is a little
> faulty here.

But not as faulty as yours.  I maintain that the expression syntax
should be kept as close as possible to accepted mathematical conventions.
You seem to be maintaining that, because exact duplication is not possible,
the language designer shouldn't even try to be similar.  If you would
read my entire statement (in which I said that both C _and_ Fortran were
far from perfect), you wouldn't be accusing me of claiming that assignment
is a mathematical syntax.

> |The choice I'm talking about is whether to cause a function call (the
> |most expensive of all the 'simple' operations).  Doesn't matter what the
> |subroutine library does, you've already made the expensive call.
> 
> A function call may not necessarily be made (can you say 'inlining').

I can not only SAY it, I can also notice that C doesn't do it (as I've
pointed out before).  The C language definition (such as it is) doesn't
allow it.  The proposed ANSI C will, I am led to believe, address this
issue.
> 
> |Fine, C is fixing something that shouldn't have been broken to begin with.
> 
> It was never broken (a little inefficient, but not broken).

If the presence of an exponentiation operator can be considered as an
'error' in Fortran, then an inherently inefficient part of C can be
considered 'broken'.
> 
> |Finally!  Something we agree upon.  But what does this have to do with
> |the value of placing the operator into the syntax?  Just because it's
> |seldom used for large or non-constant arguments, doesn't mean it needs
> |to be arcane or cryptic when it IS used.
> 
> If all the arguments are constant, what do you need a run-time operator
> for?

The language used above was English.  I will attempt to translate it for
you.
Example:
I don't put cream in my coffee very often, but that doesn't mean that
cream shouldn't be available.
Example:
I don't use large, non-constant, or non-integer exponents very often, but
that doesn't mean it should be hard for me to do so if I wish.  Nor should
it be hard for me to use the small, constant, or integer exponents that I
use more frequently. (What's a 'run-time operator'?  All operators are
source code objects.)

Since I don't know what language you actually use, I can only hope that
several similar English examples will be sufficient.

J. Giles
Los Alamos