peters@cubsvax.UUCP (Peter S. Shenkin) (04/25/86)
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
Peter S. Shenkin Columbia Univ. Biology Dept., NY, NY 10027
{philabs,rna}!cubsvax!peters cubsvax!peters@columbia.ARPAminer@ulowell.UUCP (Richard Miner) (05/04/86)
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."
pmontgom@sdcrdcf.UUCP (Peter Montgomery) (05/07/86)
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.
gast@ucla-cs.ARPA (David Gast) (05/08/86)
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
levy@ttrdc.UUCP (Daniel R. Levy) (05/08/86)
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
franka@mmintl.UUCP (Frank Adams) (05/12/86)
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
gast@ucla-cs.UUCP (05/22/86)
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