Path: utzoo!attcan!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!purdue!i.cc.purdue.edu!h.cc.purdue.edu!s.cc.purdue.edu!ags
From: ags@s.cc.purdue.edu (Dave Seaman)
Newsgroups: comp.lang.fortran
Subject: Re: An exercise in futility (was Results of the UGLY code)
Summary: It STILL is completely UNambiguous.
Keywords: Cumulative_Annual_Pocket_Part
Message-ID: <3698@s.cc.purdue.edu>
Date: 2 Jan 89 20:05:56 GMT
References: <583@mbph.UUCP>
Reply-To: ags@s.cc.purdue.edu (Dave Seaman)
Organization: Purdue University
Lines: 78

In article <583@mbph.UUCP> hybl@mbph.UUCP (Albert Hybl  Dept of Biophysics  SM) writes:
>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
>
>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? :-(

 [some additional remarks about ambiguity deleted]
				^^^^^^^^^

We must have been following different discussions.  The discussion that I
followed with respect to this code example arrived at the conclusion that
it is flatly and unambiguously illegal.

What is confusing the issue is that the standard does not require a
standard-conforming processor to refuse to compile any program that is
nonstandard.  The processor is permitted to compile anything it likes, and
to assign any meaning that the implementor deems convenient or desirable.
This is a deliberate decision on the part of the standards committee.  It
will not and should not change.  The reason is that changing this part of
the standard would make it impossible for vendors to offer extensions to
the language.  Ruling out extensions would be a tragic error, indeed.
Without them there is unlikely to be much progress in the standard.

In other words, it is permissible for a standard-conforming processor to
accept the input

	'Twas brillig, and the slithy toves

as a legal extended Fortran program, and for the program to print the
answer, "42" when executed.  A second processor might cause the result,
"Lewis Carroll", to be printed.   A third processor might complain of
syntax errors and refuse to compile the program.

All three behaviors are perfectly correct.  None of them is ruled out by
the standard, nor should they be.  There is no ambiguity.  Those who would
tinker with the standard should first understand what it is that the
standard attempts to prescribe and what the standard deliberately refrains
from prescribing.

>The purpose of the Fortran ANSI X3.9 1978 standard "is to
>promote portability of FORTRAN programs for use on a variety
>of data processing systems."  The result of Steve's survey
>shows that not even a simple double do loop is immune to
>ambiguity when tested for horizontal portability.  
 ^^^^^^^^^

Why not take another survey, based on the "slithy toves" example?  One
processor might say, "Unable to recognize statement."  Another might say,
"string too long".  Another might say, "invalid expression on left side of
assignment statement".  It is theoretically possible, but unlikely, that
some processor might actually accept it as a legal program.  Does all this
mean that the standard is ambiguous in failing to specify a behavior for
the "slithy toves" input?

Nothing is immune to ambiguity when subjected to tests that that are based
on faulty logic.  When tested correctly, by READING THE STANDARD, the
apparent ambiguity disappears completely.  The program is flatly illegal,
which automatically makes it clearly and unequivocally non-portable.  End
of portability discussion.

-- 
Dave Seaman	  					
ags@j.cc.purdue.edu