Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!bionet!ames!haven!uvaarpa!mcnc!ecsvax!urjlew
From: urjlew@ecsvax.UUCP (Rostyk Lewyckyj)
Newsgroups: comp.lang.fortran
Subject: Re: DO loops, anyone?
Summary: I disagreeDix Fix the standard
Message-ID: <6676@ecsvax.UUCP>
Date: 16 Mar 89 23:41:50 GMT
References: <458@orange19.qtp.ufl.edu> <28506@sgi.SGI.COM> <1317@uw-entropy.ms.washington.edu>
Organization: UNC Educational Computing Service
Lines: 59

In article <1317@uw-entropy.ms.washington.edu>, charlie@mica.stat.washington.edu (Charlie Geyer) writes:
> 
> In article <6667@ecsvax.UUCP> urjlew@ecsvax.UUCP (Rostyk Lewyckyj) writes:
>  
> > I think that the rational solution is to amend the standard (put it
> > in 8x or 9x if 8x never makes it) to require DO loops to be terminated
> > one at a time with CONTINUE or ENDDO statements.
> > I realize that this will require modifying old source.
> 
> A simpler solution would have compilers do run-time error checking and
                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ???
By run time the compiler is long gone 8-). 
  
> not jump into inactive loops.  The beauty of this solution is that it
> does not not slow down structured code -- no checking necessary.
> 
> Unstructured code would take a performance hit.  Serves it right :-)
> 
If you are dynamically checking your branches at run time you are
using time to do it , i.e. taking a performance hit     NO???
  
> It's not failure to end every loop with its own CONTINUE that is the
> problem.  It is (surprise!) GOTO's are harmful.
  
Baloney! It isn't goGOTOs that are harmfull, its spagetti code that
attempts to bend the legal limits of the rules,and and is convoluted
either because the programmer can't do better or is attempting to
be clever., that is bharmfull.
  
Let me slightly amend my recommentdations.
Pro1 Prohibit gotbranches into the scope of a DO loop, whether to a statement
well inside the loop or the terminal statement. CThExcept to the DO state-
ment itsleelf from a statement outside the DO.
2 Prohibit the extended range of the DO. i.e. branching out of the DO
and then back in.
3 Require a each DO loop to be terminated by its own ENDDO, which can not
be the target of a branch.
  
I am suggesting these stricter rules because I realize that my previous
suggestions could still get misused by transbranching from outside a loop
to the terminal cCONTINUE of any loop. 
  
If the standard were amended in this way , then probabbly a great 
amount of special rules and interpretations could be removed, Thus
making the language more robust and simplifying the standard at the
same time.
Since the adherence to the rules I propose should be checkable 
at compile time there would be no run time performance penalty.
I also think that , bthese changes would permit better program srtructure
analaysis by the compiler and the production of more optimized code.
The onl y problem I see with my suggestions are the at rule 2 will
break too many codes.


-----------------------------------------------
  Reply-To:  Rostyslaw Jarema Lewyckyj
             urjlew@ecsvax.UUCP ,  urjlew@tucc.bitnet
       or    urjlew@tucc.tucc.edu    (ARPA,SURA,NSF etc. internet)
       tel.  (919)-962-9107