Path: utzoo!attcan!uunet!decwrl!sdd.hp.com!cs.utexas.edu!asuvax!noao!stsci!ansok
From: ansok@stsci.EDU (Gary Ansok)
Newsgroups: comp.lang.fortran
Subject: Re: Function calls in the middle of subroutine CALLs? -- Is it standard fortran 77 ????
Message-ID: <1644@stsci.edu>
Date: 1 Aug 90 14:06:00 GMT
References: <2009@key.COM> <58237@lanl.gov>
Reply-To: ansok@stsci.edu.UUCP (Gary Ansok)
Organization: Space Telescope Science Institute, Baltimore, MD 21218
Lines: 35

In article <58237@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>From article <2009@key.COM>, by sjc@key.COM (Steve Correll):
>> [...]
>> 	X .GT. Y .OR. L(Z)
>> 
>> where L is a logical function which defines its dummy argument. The standard
>> says that if X is greater than Y, then Z becomes undefined. Not very user-
>> friendly, but Fortran programmers have traditionally been tough as nails.
>
>Since this started as a comparison to C, let's remember that C is just
>as bad here.  You can't predict a-priori whether the function L() will
>be executed in either language.  In pretty much any language, it's a
>bad idea to have functions with side-effects in a context like this.

Well, sort of.  For the C equivalent

	(x > y) || l(&z)

you cannot tell just by looking at the statement whether l() will be
called or not.  However, you are guaranteed that if (x > y) is true,
then l() will NOT be called and if (x > y) is false, l() will be
called.

Fortran makes no such guarantees -- if (X .GT. Y) is false, L() must
be called, but if (X .GT. Y) is true, then L() MAY OR MAY NOT be
called, at the whim of the compiler.

I agree that functions with side-effects, especially in a context like
this, can be confusing and often lead to subtle bugs.  However, the
stop-as-soon-as-possible guarantee of C has its uses, and I certainly
prefer it to the whatever-the-compiler-feels-like to Fortran.

- Gary

-- Gary