Path: utzoo!utgpu!attcan!uunet!seismo!sundc!pitstop!sun!decwrl!labrea!rutgers!mailrus!purdue!i.cc.purdue.edu!h.cc.purdue.edu!ags
From: ags@h.cc.purdue.edu (Dave Seaman)
Newsgroups: comp.lang.fortran
Subject: *THE GENERAL CASE* (was: function side effects)
Message-ID: <3999@h.cc.purdue.edu>
Date: 21 Sep 88 21:49:04 GMT
References: <3987@h.cc.purdue.edu> <3821@lanl.gov>
Reply-To: ags@h.cc.purdue.edu.UUCP (Dave Seaman)
Organization: Purdue University
Lines: 70

In article <3821@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>If you want to talk about side effects in general - fine.
>Read section 1.4 of the standard document.  

I already have.  It supports my position that side effects are allowed
except where specifically prohibited.  Here is the exact quote:

	An executable program (2.4.2) conforms to this standard if it uses
	only those forms and relationships described herein and if the
	executable program has an interpretation according to this
	standard.

I was already planning to use section 1.4 as the basis for building my
case before you mentioned it.  Precisely because of this statement, if you
wish to claim that side effects are not allowed, the burden of proof is on
you to show that:

	(1) they use forms and relationships not described in the standard,
	(2) they do not have an interpretation according to the standard,
or	(3) they are explicitly forbidden by the standard.

Before I proceed, a reminder.  The subject line describes the topic that I
am discussing.  It is your topic.  You brought it up.  It would never have
occurred to me to discuss this if you had not pursued it.  If you have
something to say on a different topic, fine -- but please use an
appropriate subject line. 

Let us consider the proposition that the standard committee _intended_ to
outlaw _all_ side effects.  I believe the following language would have
done the trick quite nicely:

	1.  External functions may not modify their dummy arguments.
	2.  External functions may not modify variables in COMMON.
	3.  External functions may not contain SAVE statements.
	4.  External functions may not perform input/output operations.
	5.  External functions may not call (directly or indirectly) 
	    subroutines that do 2, 3 or 4, or which modify dummy arguments
	    of the external function.

I guess the committee _intended_ to do this, but they just forgot.

The fact is that the committee explicitly contradicted points 1 and 2, and
they implicitly (because of section 1.4) contradicted the rest.

Michael Metcalf and John Reid are members of the committee.  On page 80 of
their book, "Fortran 8X Explained", they say:

	It is permissible to write functions that change the values of
	their arguments, modify values in modules, or perform input-output
	operations. [...]

	In order to assist an optimizing compiler, the standard prohibits
	certain side-effects. [Examples given]

If Metcalf and Reid ever intended to disallow all side effects in
functions, they have apparently changed their minds.  The clear intent is
to disallow only those side effects which might inhibit optimization.

>Still, you haven't addressed the REAL issue that _I'm_ interested in -
>should side effects be allowed where Fortran currently doesn't allow
>them?  

That's easy.  The answer is no.  Those side effects that are currently not
allowed have been ruled out for very good reasons.  We should be doing the
opposite:  looking for side effects that are legal, but shouldn't be.  I
would mention an example, but I can't.  That would be changing the
subject.
-- 
Dave Seaman	  					
ags@j.cc.purdue.edu