Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!ltuxa!ttrdc!levy
From: levy@ttrdc.UUCP (Daniel R. Levy)
Newsgroups: net.lang.f77
Subject: Re: f77 bug:  comparing logicals
Message-ID: <860@ttrdc.UUCP>
Date: Wed, 7-May-86 23:10:48 EDT
Article-I.D.: ttrdc.860
Posted: Wed May  7 23:10:48 1986
Date-Received: Sat, 10-May-86 07:04:27 EDT
References: <464@cubsvax.UUCP> <303@ulowell.UUCP>
Organization: AT&T, Computer Systems Division, Skokie, IL
Lines: 55

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