Xref: utzoo comp.lang.fortran:313 comp.sources.wanted:2806
Path: utzoo!mnetor!uunet!husc6!bu-cs!scott@bu-ma.bu.edu
From: scott@bu-ma.bu.edu (Scott Sutherland)
Newsgroups: comp.lang.fortran,comp.sources.wanted
Subject: Re: ratfor to f77 preprocessor
Message-ID: <871220161548@euler>
Date: 20 Dec 87 21:15:48 GMT
References: <871218123142@euler> <254@tsc.DEC.COM>
Lines: 36
In-reply-to: pete@tsc.DEC.COM's message of 19 Dec 87 17:41:00 GMT


In article <254@tsc.DEC.COM> pete@tsc.DEC.COM (Pete Schmitt) writes:
]
] In article <871218123142@euler>, scott@bu-ma.bu.edu (Scott Sutherland) writes:
] > 
] > Does anyone have (or know where I can get) a ratfor that produces f77?
] > I like using ratfor, but debugging is a pain because of the ugly
] > old-style fortran it produces.  Can anyone help? This is for a Sun 3
] > system.
] > 
] f77 if given a *.r file assumes that the file is ratfor and convert it
] to f77.  I believe this is the way it was implemented on UNIX by the
] guys at Bell Labs.
]

I guess I wasn't too clear in my request.
When I said "produces f77", I really meant "produces code that takes
advantage of f77 constructs".  The main problem here is when I want to
use a debugger, in which case I have to compile by first getting
ratfor to build a .f file, then invoking f77 on that file (so that the
source matches the symbols built by the -g option).  The problem is
that the fortran produced by ratfor  doesn't use if/else constructs
and so on, so the code I debug is much more spaghetti-like than it
needs to be.  In fact, aside from the debugging problem, I can't get
ratfor to accept certain valid f77 constructs, for example

if (a.eq.b) ...
elseif (a.lt.b) ...
else ...
endif

Of course, I can code around these things, I'd just rather not.


Andrew Kailhofer at Wisconsin has suggested I use efl instead; Sun
doesn't ship efl as part of the standard distribution -- If somebody
knows of a PD efl implementation, I'd be willing to look at that too.