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