[comp.lang.fortran] Fortran could learn from C

dgh%dgh@Sun.COM (David Hough) (02/20/88)

The Fortran draft public comment
period is about to close and the C comment period is about to open.

comp.lang.c readers who've been irritated by suggestions that
C could learn some things from Fortran might be slightly
surprised to learn that I suggest that Fortran could
borrow from C as well.   The following excerpts from
the Fortran comments I'm writing relate to C.

Comment #5, Section 3.3:        Source form and  significant blanks

     The Draft should only standardize the modern  free-form
source format with significant blanks, so that newly written
Fortran programs will reflect the  progress  in  programming
language design since Algol-60.

     In addition, to take care of the vast amounts  of  code
in dusty decks, the Draft should require that an implementa-
tion provide means whereby any valid Fortran-66 or  Fortran-
77  program  can be translated automatically to a valid For-
tran 8x program in the free-form source  format.   I  expect
that  a  public-domain  implementation  of such a translator
would soon become available;  a  preprocessor  ought  to  be
incorporated into the standard anyway as discussed next.

Comment #6, Section 3.3:        C preprocessor and #include

     One common complaint about the Draft is  that  is  does
not  provide  an  include-file mechanism; a response is that
include-files are no longer necessary for common definitions
and the like because of the new module interface facility.

     Both the complaint and the response are over-simplified
and  could  perhaps  be  easily resolved if it was more gen-
erally recognized in the Fortran community that  most  large
scientific computing sites have at least some systems with a
tool installed called the C preprocessor, sometimes provided
as  part of a C compiler, sometimes separately.  Its defini-
tion is currently being standardized by X3J11.  An implemen-
tation by the Free Software Foundation is widely available.

     The best course would be to incorporate the  definition
of  the  C  preprocessor into the Fortran 8x draft.  Despite
its many shortcomings, its already  widespread  availability
makes the C preprocessor syntax the choice for providing the
include-file capability, and much more,  in  Fortran.   Most
Unix  systems  already  allow  Fortran  source  files  to be
optionally preprocessed thus.  Its  usefulness  is  somewhat
limited  by  the  restricted line-oriented Fortran-77 source
format, which is another reason why Fortran 8x should decre-
ment that format.

     The Fortran preprocessor  could  also  be  expanded  to
optionally provide the Fortran-66 or Fortran-77 fixed source
format conversion to free form, although that function might
be better left to a separate processor to encourage it to be
done once and for all, rather than on every compilation.

David Hough

ARPA: dhough@sun.com
UUCP: {ucbvax,decvax,decwrl,seismo}!sun!dhough

eugene@pioneer.arpa (Eugene N. Miya) (02/21/88)

Just a short note on your comment.

Years ago in grad school, I had a visiting French professor of CS who
had a great little cartoon on this problem.  A man (standing) (FORTRAN
written across his suit) and a woman (sitting) (COBOL written over her)
in a living room with a baby (PL/1) on the floor.  There was a big
picture window and a milkman (ALGOL written across him) with his truck
walking up to the door.  The husband is saying:
	"He doesn't look like me...."
The baby and the milkman share the same face.  I hope I still have this
cartoon buried some place.

Face it, you will never satisify users who can't (won't) change, so you
might as well write a new language for new architectures.

From the Rock of Ages Home for Retired Hackers:

--eugene miya, NASA Ames Research Center, eugene@ames-aurora.ARPA
  "You trust the `reply' command with all those different mailers out there?"
  "Send mail, avoid follow-ups.  If enough, I'll summarize."
  {uunet,hplabs,hao,ihnp4,decwrl,allegra,tektronix}!ames!aurora!eugene

henry@utzoo.uucp (Henry Spencer) (02/26/88)

> ... the C preprocessor, sometimes provided
> as  part of a C compiler, sometimes separately.  Its defini-
> tion is currently being standardized by X3J11...

Beware of one fine point, though:  X3J11 is *not* requiring that the
preprocessor be available independently of the rest of the compiler.
(They considered it but decided it was outside their jurisdiction.)
-- 
Those who do not understand Unix are |  Henry Spencer @ U of Toronto Zoology
condemned to reinvent it, poorly.    | {allegra,ihnp4,decvax,utai}!utzoo!henry

ssd@sugar.UUCP (Scott Denham) (03/05/88)

In article <42586@sun.uucp>, dgh%dgh@Sun.COM (David Hough) writes:
>      The Draft should only standardize the modern  free-form
> source format with significant blanks, so that newly written
> Fortran programs will reflect the  progress  in  programming
> language design since Algol-60.
> 
HOGWASH!!  The traditional FORTRAN 'card' image format works fine, is
what thousands upon thousands of 'casual' users of the language have come
to expect, and I'd be willing to bet is STILL the dominant for of FORTRAN
code. I think it's fine that a 'modern' variation is allowed, or even
encouraged, but to take away the old would be pointless and would 
ABSOLUTELY GUARANTEE the rejection of the standard. Beleive me, there are
lots of FORTRAN users out there who think the standard should be frozen
at '77 forever. If they wanted a 'modern' language, they'd be using one!
 (discussion of INCLUDE and pre-processor deleted)
 
>      The best course would be to incorporate the  definition
> of  the  C  preprocessor into the Fortran 8x draft.  Despite
> 
Again I disagree. I think pre-processors are great, but let's not burden
an already unwieldy standard document with another whole language, and 
let's not force the compiler vendors to provide one to gain certification
under the 8x standard. What might be nice is to have a standalone 'standard'
for a language front-end preprocessor. Remember that EVERONE will have to
pay for all the bells and whistles that get tacked onto the standard. 
Many of us have no need for such a pre-processor or already have one that
is known and loved - we don't want to pay for another one!! Tom Lahey
has already estimated the effort at converting his 77 compiler to 8x at 
2-3 times the difficulty of writing the original 77 from scratch! Lets
not go for 4; I'm not ready for $1000 micro compilers or $2000/mo mainframe 
ones!
> David Hough
> 
> ARPA: dhough@sun.com
> UUCP: {ucbvax,decvax,decwrl,seismo}!sun!dhough
  
                                                Scott Denham