Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!umich!yale!cmcl2!lanl!lambda!jlg
From: jlg@lambda.UUCP (Jim Giles)
Newsgroups: comp.lang.misc
Subject: Re: NOT Educating FORTRAN programmers to use C
Message-ID: <14216@lambda.UUCP>
Date: 25 Jan 90 02:42:27 GMT
References: <11962@stealth.acf.nyu.edu>
Distribution: usa
Lines: 106

From article <11962@stealth.acf.nyu.edu>, by brnstnd@stealth.acf.nyu.edu:
> Normal Fortran has only two advantages over C, namely a wider set of
> standard builtins and a larger support base. Fortran 90 loses the
> support base (why did X3J3 have to change the comparison names?) [...]

Huh?  Fortran 90 is _supposed_ to be backward compatible to Fortran 77.
I know of a couple of really obscure contradictions (which the committee
is presently fixing).  I don't know _any_ compatibility problem that
relates to the syntactic form of comparisons.

> [...]                                                           and
> adds just two other advantages: named loops and the multilevel break. 

And - array syntax, non-aliasing dynamic memory, user defined operators,
overloaded procedures (with type checking of arg types required), etc..

C++ has _some_ of these.  No ordinary C (ANSI or not) has any of them.
ANSI C leaves the door open slightly) with function prototypes, but
all function definitions with the same function name must return the
same type!

> Other articles list many of the advantages of C over Fortran.

Maybe you should have listed them again.  So far, the only one I can
think of is dynamic memory.  This advantage is offset by the innefficient
code generated because pointers (even to dynamic memory) must be assumed
to be aliased.  It is further offset by the fact that most Fortran
environments already provide a (non-standard, I know) form of dynamic
memory.  And, before you say that it's useless if it's not portable,
I could use the same argument about the future possibility of 'noalias'
pragmas in C - and, by the time _those_ are available, the new Fortran
standard will be providing portable dynamic memory constructs which are
_automatically_ non-aliasing.


> [...]
> I favor C over Fortran, and I know what Fortran 90 offers. (Back in 1987
> I listened to a talk on the Fortran 8X draft, and my two questions were
> ``Won't compilers for such a huge language be rather inefficient?'' and
> ``Is it really Fortran?'' The answers are ``yes'' and ``no'' respectively.)

Whoever gave the talk was misleading you.  In terms of difficulty of
implementation, Fortran 90 is not much worse than C:

      Derived types are the same as C's 'structs'.
      C has 'unions', Fortran 90 doesn't (darn) - so Fortran is simpler here.
      The new KIND attributes are no worse than C's plethora of types.
      The new flow control (CASE, DO WHILE, CYCLE, EXIT, etc.) are about
            the same as C.  Fortran is actually simpler since 'blocks'
            aren't separate scopes as they are in C.
      Fortran 90 has interface blocks, which serve a function similar to
            ANSI C's function prototypes.  Both would cost about the same
            to implement but Fortran allows procedures to be overloaded
            and C doesn't.
      Fortran 90 allows overloaded and user-defined operators.  C doesn't
            (not even ANSI C).  The cost of implementing such operators
            is about the same as overloaded procedures (and is done the
            same way: with interface blocks).  The only additional work
            is to modify the parser to recognize user defined operators
            (parsers are the most automated part of compiler construction,
            A simple grammar change is sufficient to change the operator
            into the corresponding function call - which is possible
            'inlined' if the function is defined in the same MODULE
            as the call).
      Fortran 90's MODULEs introduce a scoping mechanism that is basically
            identical to C's use of 'files'.  The implementation cost should
            be about the same.
      Fortran 90's ALLOCATABLE attribute gives Fortran the same capabiltiy
            as C's malloc()/free().  It is about the same difficulty to
            implement except that ALLOCATABLE objects are _known_ not to
            be aliased - so they optimize better.
      Fortran 90's pointers are abominable.  Used as simple pointers (in
            linked lists and such) these pointers are simpler than those
            in C (no pointer arithhmetic).  Pointers to array slices are
            terrible: they add _NO_ functionality to the "whole array"
            syntax, but they introduce the possibility of aliasing which
            wouldn't be there without them.  Nevertheless, there is a
            simple (but inefficient) way to implement these.  Since I
            don't believe they _CAN_ be made efficient, this simple
            implementation is all they deserve.
      Etc..

In fact, the only part of Fortran 90 that is intrinsically _different_
from some corresponding part of ANSI C is the "whole array" functionality.
The reason is that C _doesn't_have_ anything of the sort.  The question
is, is it really all that hard to implement?

Well, yes and no.  There are very simple implementations which might provide
all the performance you need on a scalar machine, but which would be very
inefficient on a parallel machine.  On the other hand, the vendors of
parallel hardware have spent almost a decade finding ways to optimize
array operations - this might even simplify their task since they will
no longer have to analyse nested loops just to find what array operations
are really being performed.  I don't think this particular feature will
be a major stumbling block.

> [...]
> As for aliasing, I don't see any sequential optimizations hurt by it
> that shouldn't be done by hand in any case.

Boy, I'm impressed.  You actually do strength reduction, common expression
elimination, elimination of loop invariants, register and cache scheduling,
etc. ALL BY HAND?  Wait a minute - you'd have to use assemble exclusively
in order to do all that!

J. Giles