Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!mailrus!ukma!rutgers!cs.utexas.edu!oakhill!steve
From: steve@oakhill.UUCP (steve)
Newsgroups: comp.lang.fortran
Subject: Dubious Fortran Construct (Was: An exercise in futility)
Summary: What should we do?
Keywords: DO LOOP ambiguous
Message-ID: <1762@devsys.oakhill.UUCP>
Date: 3 Jan 89 20:04:04 GMT
References: <583@mbph.UUCP>
Organization: Motorola Inc. Austin, Tx
Lines: 74

In article <583@mbph.UUCP>,
hybl@mbph.UUCP (Albert Hybl  Dept of Biophysics  SM) writes:
> 
> In message-ID: <1750@devsys.oakhill.UUCP>, Steven R Weintraub, 
> Motorola Inc. Austin, Texas--cs.utexas.edu!oakhill!devsys!steve,
> summarized the results of his "UGLY" code problem run on about 24
> different compilers.  The test problem was:
> 
> >      K = 0
> >      DO 10 I = 1,10
> >        IF (I.EQ.1.OR.I.EQ.5) GOTO 10
> >        DO 10 J = 1,10
> >          IF (J.EQ.3) GOTO 10
> >   10 K = K + 1
> >      PRINT *,K
> >      END
> 
> Half of the fortran implementations produced an ERROR diagnostic;
> the other half gave numeric answers having the disparate values 80,
> 82 or 92.
> 
> Steve has shown that the USENET can be used to rapidly discover
> ambiguities in a language standard.  Discussions in this newsgroup  
> can propose corrective language to eliminate ambiguities from
> the standard.  The real problem is how to incorporate the new
> language in a standard that has been chiseled in stone?  Must
> we wait for FORTRAN8x? :-(

I think you now understand the reason I posted the example.  This
case was so ambigous that there were three correct responses, and a
large portion of machines generated wrong responses.  If you remember
my initial post, I said there should be an unambigous interpretation
for this code, and I gave four choices to decide on.  These were:

1) Code is illegal.  This interpretaion is what some people in the
   ANSI committee probably want.  Unfortunately I think the standard
   on this point is to vague.  Also it flies in the face of common
   coding practice.

2) Code is illegal, except where the last statement is a continue
   statement.  This solves the ambigous interpretations for this
   code, but is slightly arbitrary. 

3) That the code should interpret the K = K + 1 as part of the internal
   loop.  This is probably what the writer of such code had in mind
   when writing it.  It also makes compiler generation easy.

4) That the code K = K + 1 is part of both loops.  This is messy,
   proabably not what the programmer had in mind, and the attempt
   to generate this code is what caused most of the compilers tested
   generate the result 92.

In my concurrent postings, I state there needs to be a way to input
user desires to the standard committees.  The net might be one such source.
So let's discuss.  I personally believe that choice #3 is best.  It allows
for current user practice (or some say misunderstanding) of FORTRAN while
clearing out the ambiguity.  I also think this would be what most users
intend when they code like this.  Since I put a CONTINUE on every label,
I technically avoid this ambiguity.  I personally believe #1 is out of the
question.  The job of a standards committee should be to define standard
use and expand it unobstructively as new theory as structures arise.
Since this structure seems to be in standard use, saying it is illegal
oversteps what I think a standards committee should do.  What do you
folks think.

                   enough from this mooncalf - Steven
----------------------------------------------------------------------------
These opinions aren't necessarily Motorola's or Remora's - but I'd like to
think we share some common views.
----------------------------------------------------------------------------
Steven R Weintraub                        cs.utexas.edu!oakhill!devsys!steve
Motorola Inc.  Austin, Texas 
(512) 440-3023 (office) (512) 453-6953 (home)
----------------------------------------------------------------------------