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