Path: utzoo!attcan!uunet!pyrdc!pyrnj!rutgers!cmcl2!lanl!jlg
From: jlg@lanl.gov (Jim Giles)
Newsgroups: comp.lang.fortran
Subject: intrinsic functions, math operators (was: i++, i+=1, i=i+1)
Message-ID: <3748@lanl.gov>
Date: 19 Sep 88 20:28:32 GMT
References: <1531@ficc.uu.net>
Organization: Los Alamos National Laboratory
Lines: 37

From article <1531@ficc.uu.net>, by peter@ficc.uu.net (Peter da Silva):
> This is not true. Just because something in 'C' has the form of a function
> does not mean it is forced to be a function:
> 
> 	getchar()
> 	min()/max() on many machines
> 	feof()
> 	isprint()
> 

This is one of the reasons that C is less portable than Fortran.  The set
of intrinsic functions is not defined anywhere.  I may indeed want to write
my own versions of some of the above functions (add pow() to the list).  If
one implementation allows me to do so, another shouldn't prevent me - unless
the standard says that the function is intrinsic - in which case, the 
implementor is allowed to switch.  The present C 'standard' (such as it is) 
is K&R.  K&R doesn't mention any intrinsics as far as I know.  As I said 
before, the ANSI C standard will probably address this issue.

>> A secondary objection is that
>> exponentiation is a mathematical operation for which mathematicians
>> and others have always had (and still expect) a shorthand syntax.
> 
> This syntax is, however, not the one Fortran uses. The mathematical syntax
> for exponentiation is actually not displayable in ASCII text.

That is _not_ a valid argument for omitting exponentiation as an operator.
Subscripting is not expressible in ASCII text either.  Yet both Fortran
_AND_ C have a syntax for subscripting.  I would argue (as I have before)
that the syntax for mathemetical operations in a programming language
should be as close as possible to the syntax used by the target user
community for those same operations.  Constraints of the character set
and of the compiler may prevent you from getting _exact_ identity with the
user's preferred syntax - but you should still try to get close.

J. Giles
Los Alamos