🚀 go-pugleaf

In article <1456@mmintl.UUCP> franka@mmintl.UUCP (Frank Adams) writes:
>In article <12846@ucla-cs.ARPA> gast@ucla-cs.UUCP (David Gast) writes:
>>Now to the example at hand.  F77 does not allow the .eq. operator
>>between logicals.  There is a syntax error not detected by the 
>>compiler. Isn't FORTRAN a great language?
>
>Why do you blame the language after (correctly) identifying the compiler as
>being at fault?

(The best is saved for last)

In the first place, why should the language have different operators?
Obviously, the compiler writers thought that it was silly or they would
not have allowed .eq. between the logicals.  

Secondly, FORTRAN is full of constructs which cannot be caught 
by the compiler and are never caught by the run-time system due 
to the extreme expense involved.  I am not just talking about 
checking for variable initializations and simple things that 
could be caught (and that could be caught without slowing the 
machine down appreciably if the machine architectures were better).  
I am speaking of things like making sure that two formal parameters 
do not alias the same memory location if one of them is "defined" 
in f77 parlance during the execution of the subroutine or function 
or any units called by it.

Part of the reason for not detecting these errors is that
initially FORTRAN was designed to be as fast as assembly language
on the particular IBM machine.  (Kind of like C and the PDP).  Error
checking would have slowed the computer down.

Thirdly, the language has changed too much through the years.
Current errors were quite possibly legal in earlier versions 
of FORTRAN.  The manufacturers do not want to produce a compiler 
that complains that something is illegal because then all those 
people with all those millions of lines of code would have to 
recompile and worse re-write their code.  (Of course the programs 
do not really work).

Here is are two examples:

         i=10
         j=1
         do 10 i = i,j
            ...
10       continue

This loop must execute exactly 0 times in f77.  It is not permitted to
let it executed once.  Futhermore, the number of times that this loop
executes in f66 is NOT once.  In f66 this loop is undefined.  Before
you start to flame, look it up in the ansi document.

        subroutine p (x)
        data a/0/
        x = a
        a = a + 1
        end

In f77 what value is assigned to x the second time p is called?  The answer 
is implementation dependent.  The f77 standard allows either a stack 
implementation (in which case the answer is 0) or the regular "static"
implementation (in which case the answer is 1).  To force the answer
to be one, the user must save the variable a.

Now I ask you "Is a language which allows two different answers for some-
thing like this a reasonable language?"  I think not.
 
David Gast

PS I have not even mentioned all of the mundane matters that get
discussed ad infinitum.

!inhp4!ucla-cs!gast