Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!pioneer.arc.nasa.gov!maine
From: maine@pioneer.arc.nasa.gov (Richard Edwin Maine  D-OFA)
Newsgroups: comp.lang.fortran
Subject: Re: DO loops, anyone?
Summary: belongs to both loops, so the code is illegal
Message-ID: <22754@ames.arc.nasa.gov>
Date: 15 Mar 89 05:20:04 GMT
References: <458@orange19.qtp.ufl.edu> <28506@sgi.SGI.COM>
Sender: usenet@ames.arc.nasa.gov
Reply-To: maine@pioneer.arc.nasa.gov.UUCP (Richard Edwin Maine  D-OFA)
Organization: NASA-Ames Research Center
Lines: 117


Calvin Vu of Silicon Graphics gives a long-winded explanation of
why he thinks the following piece of code is legal.

<<       PROGRAM LOOP
<<       IGO = 1
<<       DO 501 I = 1, 10
<<          WRITE (6,*) 'OUTER LOOP, I =',I
<<          IF (IGO .NE. 0) GOTO 501
<<          DO 501 J = 1, 5
<<             WRITE (6,*) 'INNER LOOP, J=',J
<<  501     CONTINUE
<<          STOP
<<          END

His whole argument is based on the statement that:

<The shared terminal statement belongs to both loops, but in no instance it
<belongs to both loops at once.    In other words, it can belong to either
<loop at a time but not both.   The rule as to which loop it belongs to 
<is the same as the rule for loop control processing i.e. it should belong to
<the most current active DO loop.

There is nothing like this anywhere in the ANSI standard.  In fact,
the ANSI standard (section 11.10.1) makes it quite clear that indeed
the statement DOES belong to the range of both do loops.  Nowhere does
the standard hint that a statement may not belong to the range of
multiple do loops at the same time.  Indeed, the concept of time
is not mentioned at all in conjunction with the range of a do loop.
Time relates to the activation of a do loop, but not to its range.
This claim and concept seems to come solely from the mind of
Calvin Vu (and admitedly others that seem to agree with him).  If
you claim support for this position in the standard, please provide
section reference.

Once this arbitrary rule is dismissed, all is clear.  There are no
contradictions (at least on this subject) in the standard.  The
only contradictions are with this rule, which is not in the standard.

True the terminal statement is in the range of the outer loop, which
is active.  However it is ALSO in the range of the inactive inner loop.
Therefore branching to it is illegal.  Note that nowhere do I use the
term "exclusive".  It is Calvin that is trying to argue that the
statement should belong exclusively to one loop at a time, not I.

Calvin says

<so please do not quote the following definition on the range of a DO loop 
<(which I can recite backward BTW :-)) and use it as the rule-of-thumb for
<everything:
<	11.10.1 _Range_of_a_DO-Loop_.  The _range_of_a_DO-Loop_ consists of
<	all of the executable statements that appear following the DO
<	statement that specifies the DO-Loop, up to and including the terminal
<	statement of the DO-loop.
<
<and without quoting the statement following it:
<	"More than one DO-loop may have the same terminal statement"
< ... and stuff about active/inactive loop definitions.

Ok, I'll quote em both.  And I'll claim that 11.10.1 IS the rule-of-thumb
for everything.  It is after all the standard.  Calvin's claim that
a statement cannot simultaneously be in the range of 2 loops is not
in the standard and is flatly contradicted by 11.10.1.  The statement
that more than one DO-loop may have the same terminal statement makes
no contradictions.

The business about active and inactive loops does NOT have anything
to do with the range of the loops.  You are trying to make a connection
that isn't there.  The range is a static concept that is not a function
of time.

Calvin further states

< to make this bitchy code portable and produce the correct result across 
< most computers that do not declaring this as illegal, just add one
< statement to your code outside both loops to give J a well-define value:
<
<C	Initialize J to the value of the inner loop's terminal value.
<C	This will make it works on most computers that allows this
<C	construction.    However, there are a few
<C	@#@#@% compilers (standard UNIX f77, for example) that checks for 
<C	J=6 (instead of J>5) as the terminating condition so I can't guarantee 
<C	this.
<	J = 5
<       DO 501 I = 1, 10
<         WRITE (6,*) 'OUTER LOOP, I =',I
<         IF (IGO .NE. 0) GOTO 501
<         DO 501 J = 1, 5

Yukk! In the name of "portability" you try to second guess the inner workings
of the compiler?  Remind me not to try porting any of your code.  To make
this code portable, add a continue statement with a separate statement
number as the terminator of the outer DO-loop.  This is not only portable
(really - like it'll run on anything), it is even standard.  What an odd
coincidence.

The only "reasonable" (my term, not ANSI's) thing for a compiler to
do with this code is bitch.  ANSI doesn't demand it, but I do.
(Not that I always get what I demand, but it doesn't stop me).  If
the compiler wants to invent some extension like Calvin's, I suppose
its fine with me, as long as it also warns you that this is non-ANSI.

As an aside, has anyone noticed that the draft 8X standard (at least
the Jun 87 version that I have) DOES require the compiler to provide
diagnostics for code that violates the standard?  I've never seen
much discussion of this "little" change.  I sure like it.  I've
long taken the position that "reasonable" compilers would do this,
but with this clause, I'd be able to make that position quite a
bit stronger (and includable in procurement specifications, etc.)
This would mean that if a compiler did not bitch about non-ANSI
usages (to the extent statically determinable), I could claim
the compiler was not in conformance.

Richard Maine
maine@elxsi.dfrf.nasa.gov
(sending this from maine@pioneer.arc.nasa.gov because we don't have
posting set up on elxsi).