Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!gatech!prism!loligo!mccalpin
From: mccalpin@loligo.cc.fsu.edu (John McCalpin)
Newsgroups: comp.lang.fortran
Subject: Re: yes vs. no on f8x
Keywords: f8x, x3j3, wg5, ansi
Message-ID: <590@loligo.cc.fsu.edu>
Date: 15 Apr 89 13:40:24 GMT
References: <867@a.lanl.gov> <584@loligo.cc.fsu.edu> <877@a.lanl.gov>
Reply-To: mccalpin@loligo.cc.fsu.edu (John McCalpin)
Organization: Supercomputer Computations Research Institute
Lines: 47

In article <584@loligo.cc.fsu.edu>, I wrote stuff indicating my
approval of the new draft Fortran standard.

In article <877@a.lanl.gov> alm@a.lanl.gov (Alex Marusak) replied:
>It seems to me that you have considered carefully the complexity
>issue, have measured it against the added power that Fortran 8x would
>give you, and have come down strongly in the "yes" column on "shall we
>have Fortran 8x?"

I was a bit confused by Marusak's first posting, in which he implied 
that the new complexity of the language *in itself* was a negative
factor. As I pointed out, FORTRAN-77 codes will be completely supported,
so this is a moot point, and one I have not heard before from informed
commentators.

The objection that I *have* heard repeatedly is more like:
    Complexity is only a problem because it will destroy the efficiency
    of Fortran compilers/optimizers, and Fortran is the only language that
    we have that is both portable and efficient. (Apologies to C)

This seems to me to be a substantive issue.  I happen to work in
vector-supercomputer-land, where efficiency is not a problem.  My codes
will simply change from several thousands of lines of sequential DO loops
to a few thousand lines of array notation.

I do not know what will happen on scalar machines.  For example, I have
heard it rumoured that DEC opposes the array notation because the need
to pass an array descriptor (rather than just a pointer to the start of
the array) forces one more level of indirection in array references,
and that this is a bad thing on a VAX.  Although I would guess that
this potential trouble could be optimized away, it is this sort of
information is what is needed to judge the efficiency issues.

It is precisely this hard information on what the new standard will
require compilers to do that is missing in this newsgroups discussions.
Are there any compiler writers out there that want to enlighten us?


>It does NOT mean you're wrong.  It does NOT mean you're right.
>It means that X3J3 has a big, big problem.

Yup.
-- 
----------------------   John D. McCalpin   ------------------------
Dept of Oceanography & Supercomputer Computations Research Institute
mccalpin@masig1.ocean.fsu.edu		mccalpin@nu.cs.fsu.edu
--------------------------------------------------------------------