🚀 go-pugleaf

In article <464@cubsvax.UUCP> peters@cubsvax.UUCP (Peter S. Shenkin) writes:
>The following program, compiled with f77, prints "f" for all three
>comparisons;  under VMS, using dec fortran,  the three results are
>"T", "F" and "T", as one would expect.
>
>cccccccccccccccccccccccc BEGIN HERE ccccccccccccccccccccccccccccccccccccccc
>	write(6,*)'.true. .eq. .true. :', .true. .eq. .true.
>	write(6,*)'.true. .eq. .false. :', .true. .eq. .false.
>	write(6,*)'.false. .eq. .false. :', .false. .eq. .false.
>
>	stop
>	end
>cccccccccccccccccccccccc END HERE cccccccccccccccccccccccccccccccccccccccccc

  The error is not that you get F F F as a result, the error is that the
compiler does not complain. .eq. and .ne. are not valid when used
with logical variables. They are for checking equalities with numeric
variabled not for checking equivalance. You should use .eqv. and .neqv.
for checking equivalence of logical variables and values.
  I found this out when porting our 36,000 line Graphical Kernel System -GKS
to the apollo. The F77 compiler on the system is not forgiving at all! The
biggest problem is the Brain damaged Fortran compiler under VMS. It lets 
you get away with too much non-standard code, even if you compile /standard.
  I will never recomend using VMS with FORTRAN as a development environment,
poor tools and as far as I am conserned a nasty compiler. I was talking to
a DEC Rep and he said that many people (at DEC) feel you should not port to
other environments, what an attitude!
  Most people have been asking for the GKS in C under Unix anyway. While
I am on the subject, we are writing our own Fortran -> C translator, does
anyone know of an existing one, in the PD preferably.
UUCP: !wanginst!ulowell!miner    Rich Miner
ARPA: miner@ulowell.CSNET        University of Lowell, Comp Sci Dept
TALK: (617) 452-5000 x2693       Lowell MA 01854 USA
HAL hears the 9000 series is not selling. "Please explain Dave. Why 
aren't HAL's selling?"  Bowman hesitates. "You aren't Amiga compatible."

In article <464@cubsvax.UUCP> peters@cubsvax.UUCP (Peter S. Shenkin) writes:
>The following program, compiled with f77, prints "f" for all three
>comparisons;  under VMS, using dec fortran,  the three results are
>"T", "F" and "T", as one would expect.
>
>	write(6,*)'.true. .eq. .true. :', .true. .eq. .true.
>	write(6,*)'.true. .eq. .false. :', .true. .eq. .false.
>	write(6,*)'.false. .eq. .false. :', .false. .eq. .false.
>	end
>
FORTRAN 77 does not permit the .EQ. operator on logical operands.  It
behaves properly under f77 if the operators are changed from .EQ. to
.EQV..
-- 
			Peter Montgomery

	{aero,allegra,bmcg,burdvax,hplabs,
	 ihnp4,psivax,randvax,sdcsvax,trwrb}!sdcrdcf!pmontgom

Don't blame me for the crowded freeways - I don't drive.

In article <464@cubsvax.UUCP> peters@cubsvax.UUCP (Peter S. Shenkin) writes:
>The following program, compiled with f77, prints "f" for all three
>comparisons;  under VMS, using dec fortran,  the three results are
>"T", "F" and "T", as one would expect.
>
>cccccccccccccccccccccccc BEGIN HERE ccccccccccccccccccccccccccccccccccccccc
>	write(6,*)'.true. .eq. .true. :', .true. .eq. .true.
>	write(6,*)'.true. .eq. .false. :', .true. .eq. .false.
>	write(6,*)'.false. .eq. .false. :', .false. .eq. .false.
>
>	stop
>	end
>cccccccccccccccccccccccc END HERE cccccccccccccccccccccccccccccccccccccccccc


When will you guys learn?  The way to figure out what the language requires
is not to write a program and see what the compiler does, but to read the
language definition and see what is required.  Surely, by now, you must have
all seen some program where the compiler makes a mistake.  For those of you
who are blind, the example at hand will suffice.

Not relying on the compiler is particularly true for FORTRAN.  In the first
place, F77 looks a lot like its older brothers, but its semantics are quite
different.  For example, boolean short circuit evaluation is permitted, but 
not required.  Second, no matter what the compiler manual says, the compiler 
does not enforce the F77 standard (or the earlier ones).  This statement
applies to the UN*X F77 compiler and to the IBM VFORTRAN compiler, for
example.  (The IBM manual also contains statements which are blatantly
incorrect, as well).  Perhaps some day, I will post a F77 program that 
has an error on almost every line--the compilers and the run-time system 
do not catch or flag or warn about any of them.

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?

If you are tired of crap like this, I suggest you throw your FORTRAN
compiler out, and get an ALGOL 68 compiler.  You won't even have to
worry about unitialized values.  And who knows, your program might
actually even work.

David Gast
gast@CS.UCLA.EDU

In article <303@ulowell.UUCP>, miner@ulowell.UUCP (Richard Miner) writes:
>  I will never recomend using VMS with FORTRAN as a development environment,
>poor tools and as far as I am conserned a nasty compiler. I was talking to
>a DEC Rep and he said that many people (at DEC) feel you should not port to
>other environments, what an attitude!

Whaddya expect?  He's not out there to sell Unix boxes (boooooooo on him!) :-).

I've heard several people complain about the "mysteriousness" of the messages
from the f77 compiler, and laud the VMS compiler's messages.  Your note is
the first comment I have seen that contradicts this experience and quite
frankly, I agree with you.  f77 points out variables that you declared but
didn't use (I've caught lots of cruft in VMS-based code this way) and don't
you think that "unbalanced quotes, closing quote supplied" is better than
a curt "%FORT-E-MISSDEL, delimiter missing..." and a useless little bitty
window into the source code line (usually a good distance away from the
starting lone quote that started all the trouble, similar comments go for
parentheses)?  And oh yeah, it numbers source code lines from the BEGINNING
of the ROUTINE, not the beginning of the file (somewhat irritating if there
is more than one routine in a file and you didn't do a FORTRAN/LIST showing
line numbers).  Of course on the plus side it is highly debugged, produces
kick-a** machine code in record time, and if the program dies it will tell
just where it died in the stack dump (though you better have a numbered
source listing handy to refer to).

>  Most people have been asking for the GKS in C under Unix anyway. While
>I am on the subject, we are writing our own Fortran -> C translator, does
>anyone know of an existing one, in the PD preferably.
>UUCP: !wanginst!ulowell!miner    Rich Miner
>ARPA: miner@ulowell.CSNET        University of Lowell, Comp Sci Dept
>TALK: (617) 452-5000 x2693       Lowell MA 01854 USA
>HAL hears the 9000 series is not selling. "Please explain Dave. Why
>aren't HAL's selling?"  Bowman hesitates. "You aren't Amiga compatible."

I've heard practically everyone and his/her uncle/aunt on the net inquiring
about these translators (variations are Fortran->Pascal, Pascal->C,
PL/1->C, ad infinitum).  My feelings are that for ANY such translator to
produce passably efficient translated code (not just "correct but slow")
that it needs to have as much knowledge as a good, optimizing compiler for
both languages involved.  I doubt that would come Public Domain or even
cheap (unless UCB or some other university gets involved in writing one
and selling at cost of copies).  It's especially hard to impose order
where there previously existed little (e.g., arbitrary-goto-laden spa-
ghetti Fortran 66 to C; I know since I've done this by hand and often cannot
easily cast out more than half of the gotos in the code structure).  Of
course if anyone knows anything to contradict this, feel free to stand up
and holler.
-- 
 -------------------------------    Disclaimer:  The views contained herein are
|       dan levy | yvel nad      |  my own and are not at all those of my em-
|         an engihacker @        |  ployer or the administrator of any computer
| at&t computer systems division |  upon which I may hack.
|        skokie, illinois        |
 --------------------------------   Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa,
						vax135}!ttrdc!levy

In article <860@ttrdc.UUCP> levy@ttrdc.UUCP (Daniel R. Levy) writes:
>It's especially hard to impose order where there previously existed
>little (e.g., arbitrary-goto-laden spaghetti Fortran 66 to C; I
>know since I've done this by hand and often cannot easily cast out
>more than half of the gotos in the code structure).

There is a wonderful program in 4.[123]BSD called `struct'.  It
was written (as I recall---I cannot find any on line documentation,
nor any author information in the source) by Dr. Brenda Baker at
Bell Labs.  It converts F66 to Ratfor, doing a truly amazing job.
Struct should be applied to all old Fortran code at least once,
just to see what it can do :-).  (I do not know if it is available
in System III/V, but if not, *why*?)

There is a story I like to tell about this program.  (It does not
seem to impress the ones it should, unfortunately; but perhaps that
is part of their very nature: else they would not use such code.)
I once managed to convince a Physics grad student that Ratfor was
better than `plain' Fortran.  But the program on which he was
working was already written, some thousands of lines of code that
had been through at least four other hands before his.  It had some
subtle bugs, and I thought the best way to flush them would be to
rewrite the whole thing in Ratfor; but he was unwilling to put that
much time and effort into what was, for him, `throwaway code'.
Of course, it had been throwaway code for each of the previous
four authors, yet it had not been thrown away.  Alas! they will
not learn from history. :-)
not learn from history. :-) )
Anyway, now I was at a loss: he had at last agreed that Ratfor was
superiour, but had a very good reason not to use it after all.
Then I found struct.  I ran his code through struct, and showed
him the result.  Struct had replaced perhaps 90% of the `goto's
with Ratfor loop constructs.  I looked closely at one of the few
remaining sections of code with gotos.  I found out why none of
the Ratfor loops sufficed for it.

It was wrong.

Alas, no, it was not `the last bug'; in fact, it was irrelevant
to the Physics student's troubles, and had probably never surfaced
at all.  It was a fencepost error on a full array, and the authors
had been careful never to fill those arrays completely.  But it
makes a good story nonetheless.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1415)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@mimsy.umd.edu

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?

Frank Adams                           ihnp4!philabs!pwa-b!mmintl!franka
Multimate International    52 Oakland Ave North    E. Hartford, CT 06108

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