Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!mit-eddie!ll-xn!ames!hc!lanl!beta!jlg
From: jlg@beta.lanl.gov (Jim Giles)
Newsgroups: comp.misc
Subject: Re: Expression syntax in programming languages.
Keywords: C FORTRAN exponentiation
Message-ID: <20666@beta.lanl.gov>
Date: 11 Jul 88 19:52:24 GMT
References: <3136@phoenix.Princeton.EDU> <19633@watmath.waterloo.edu> <5239@ihlpf.ATT.COM>
Organization: Los Alamos National Laboratory
Lines: 88

In article <5239@ihlpf.ATT.COM>, nevin1@ihlpf.ATT.COM (00704a-Liber) writes:
> If you are designing a language specifically for mathematics, then using an
> expression syntax consistent with mathematical conventions might be
> desired.  However, most of what computers are used for is not for number
> crunching.  What makes mathematical convention better than any other
> convention??

The name of this news group is comp.lang.fortran.*  Fortran IS a language
specifically designed for mathematics (formula translation - remember?).
However, all programming languages include features to support mathematical
syntax.  That portion of the language should indeed be close to normal
mathematical convention.  The thing that makes this convention better
is the prior familiarity which most people already have with this notation.
(* I know, someone cross-posted this discussion to comp.lang.c.  I didn't
do it.  Besides, someone has now switched the whole discussion to comp.misc
anyway, presumably to confuse anyone who is trying to follow it.)

> Another thing:  people tend to think of the '+' operator (with respect to
> some computer languages) as being the same as the one commonly found in
> mathematics.  These operators do not exhibit the same properties, however
> (in finite floating point arithmetic, addition is NOT associative.  I wish
> I could remember who originally posted this fact).

It's an OLD piece of information.  Should be the first thing that any
new programmer learns.  It is not the responsibility of the language
designer to protect naive users from subtle problems like this (which
they should learn anyway).  Besides, all programming languages I've
seen use the '+' operator anyway.  Surely you aren't going to suggest
changing THAT?
> 
> [...]
> Very little of what computers do correlates directly to mathematics.
> Mathematics is a declarative language, but computer languages are
> algorithmic.
> 
This argument is flawed in the same way that the others were.  If you do
very little mathematics - so be it.  But I bet you would still rather do
that little bit in the traditional syntax (or, most people would).  As I
said before, if you're going to do something for which there is already
a widely recognized syntactical convention - use the convention unless
there is a really compelling reason against it.  (By 'really compelling',
I mean avoidance of syntactic ambiguity, constraints of the character
set, or constraints of the hardware - things like that.  'Whim' is not
compelling.)

> [...  Inline code expansion ...]
>
> It has always been allowed (this is an implementation detail, not a language
> detail).

C only allows inline expansion when the source of the called routine is
available at compile time.  Since C, like Fortran, is required to permit
seperate compilation, it is required NOT to do inline expansion without
the proper 'include' file present.  Since C doesn't have the concept of
'intrinsic' functions, not even these can be expanded inline.  This was
the context of the original discussion - inline expansion of the 'pow'
function.  C can't do it (the rationale document for ANSI C admits this
as a known problem with C by explicitly allowing it in the ANSI version).

Now, if you're talking about letting the loader do code generation and
expanding code inline that way - well any language can do that!  Even
Fortran.  Since this discussion started as a C vs. Fortran on exponent
operators issue - this mechanism still doesn't favor C.
> 
> >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'.
> 
> Who said that the exponentiation operator is an error in FORTRAN?  But just

The originator of this argument did!  He claimed it was confusing to
naive users.  I claimed (and still claim) that it's less confusing than
a 'pow' function reference.

> because FORTRAN has it, that is no reason to believe that every other computer
> language should have it.  If it doesn't fit in well with the language
> paradigm, then it shouldn't be kludged in.

I agree.  But then, I don't think ANY programming language should contain
'kludged in' features.  Most do (including both C and Fortran) because
of historical development (backwards compatibility) and original design
error.  However, with respect to the exponentiation operator, including
it in C would not constitute a kludge.  It would introduce no new
ambiguities (C has some old ones) and it would introduce no burden
on those programs which don't use it.

J. Giles
Los Alamos