Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!amelia!lemming.nas.nasa.gov!fouts
From: fouts@lemming.nas.nasa.gov.nas.nasa.gov (Marty Fouts)
Newsgroups: comp.lang.fortran
Subject: Re: intrinsic functions, math operators (was: i++, i+=1, i=i+1)
Message-ID: <1028@amelia.nas.nasa.gov>
Date: 21 Sep 88 03:50:54 GMT
References: <1554@ficc.uu.net> <3907@lanl.gov>
Sender: news@amelia.nas.nasa.gov
Reply-To: fouts@lemming.nas.nasa.gov.nas.nasa.gov (Marty Fouts)
Organization: NASA Ames Research Center
Lines: 45

In article <3907@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>
>By the way, if you really believe that intrinsic functions should not be
>identified as such, you'd better hurry - the ANSI committee is about to 
>define a whole raft of them.  It is a good idea though, it helps make 
>code portable (something that C is particularly bad at).
>

1) an intrinsic function is one the compiler knows something about so
   that it can perform kicky optimizations like in line expansion.  A
   function does not have to be intrinsic to aid portability.  It need
   only be required by the standard committe.  A library
   implementation is perfectly acceptable.  If I understand correctly
   which ANSI committee you are refering to (C?) The proposal is *not*
   for intrinsic functions, but for required library functions.
   Implementation left to the implementer.


2) If a function is part of a library, rather than generated by the
   compiler, it become a matter of loader sophistication to override
   the standard version with my own version.  All I need is away to
   specify the order in which the loader locates globals, and an
   override on "multiply defined" 'errors.'

3) C is not 'particularly bad at portable code.'  I have written
   100s of K lines of code in C, Pascal, and Fortran.  Each has
   problems with portability.  For the kind of code I've written,
   ([parts of ] operating systems, compilers, data base packages,
   graphics, and  some largish numerical codes) and the kind of
   porting I've had to do, C has been much easier to deal with
   than either of the others. Your milage will vary, but there
   isn't really anything inherent in any of the languages that
   make it hard to write portable code. Or not. (During the mid 70's,
   I made    quite a bit of lose change as a consultant moving Fortran
   between IBM, DEC, Xerox and CDC machines.  I can tell you
   incredible horror stories about Fortran portability problems
   which *still* haven't been fixed.  Particularly in i/o, but
   also in other areas.)


+-+-+-+     I don't know who I am, why should you?     +-+-+-+
   |        fouts@lemming.nas.nasa.gov                    |
   |        ...!ames!orville!fouts                        |
   |        Never attribute to malice what can be         |
+-+-+-+     explained by incompetence.                 +-+-+-+