Path: utzoo!utgpu!water!watmath!clyde!bellcore!rutgers!mailrus!ncar!tank!oddjob!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.lang.fortran
Subject: Re: intrinsic functions, math operators (was: i++, i+=1, i=i+1)
Message-ID: <13635@mimsy.UUCP>
Date: 20 Sep 88 05:18:56 GMT
References: <1531@ficc.uu.net> <3748@lanl.gov>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 64

>In article <1531@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
>>... 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()

[i.e., these are often macros]

In article <3748@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>This is one of the reasons that C is less portable than Fortran.  The set
>of intrinsic functions is not defined anywhere.

`Old C' has no intrinsics (in the Fortran definition) to define, hence
the second statement is true.  The first contains two implications, one
of which is true and one of which is, at best, a matter of opinion.  C
is less portable than it might be: if `getc' is a function, the statement

	c = getc(files[index++]);

works.  On other machines, getc() is a macro that evaluates its argument
more than once, producing bizarre results.  Someone with an implementation
of the first sort can write code with embedded side effects and get away
with it; that code is not `de facto portable'.

>The present C 'standard' (such as it is) is K&R.

K&R 1st ed. is too weak a standard: the existing `de facto' standard is
much richer, but also more vague.  The semantics of `common extensions'
to K&R 1 (including such things as the math library) are not particularly
well defined, so it is hard to use these `portably'.  (All these words
are in quotes only because I am not willing to define them here now.)

>As I said before, the ANSI C standard will probably address this issue.

It does indeed.

>>[Mathematical exponentiation] 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.

True.

>... 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.

I would suggest `^', which not only looks like `go up', but also exists
in both ASCII and EBCDIC, and even appears as an up-arrow in old
ASCII.  (Before some ANSI standard whose exact number I never knew, the
characters [ \ ] and ^ were often displayed as four arrows.  Some of
you may even have four arrows showing on your screens now.  Bonus
quadrivia points to those who remember which way the arrows went :-) .)

Anyway, I happen to believe that intrinsic functions make perfectly
good `operators'.  (Just another matter of opinion.)  (I could ask
why Fortran does not have a syntax for min and max operators....)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris