🚀 go-pugleaf

In article <1633@dinl.mmc.UUCP> noren@dinl.UUCP (Charles Noren) writes:
> 1.  Data Structures.  FORTRAN IV did not have them, modern
>     FORTRAN compilers do.

If so, they are in as extensions, not as part of the (77) Standard.
Though the *next* Standard (8X -- probably 9X by now) is expected to
have them.

> 2.  Cleaner code structures.  Apparently the newer FORTRAN
>     compilers have modern code structures.  As one person
>     noted, his FORTRAN code is essentially free of statement
>     labels and indented for readability.

The 77 Standard added a lot of these.

> 3.  Recursive subroutine calls.  Most, if not all, modern
>     FORTRAN compilers can call subroutines recursively.
>     This is many a feature of the underlying implementation
>     of how arguments are passed to subroutines/functions.
>     (Question to langauge definition guru's: Are recursive
>     and reentrancy issues specified in the formal langauge
>     specifications of C and FORTRAN?)

A manufacturer's extension, which is usually easy enough to do given
the stack orientation of most O/Ses these days.  The Standard says
specifically that recursion and reentrancy are not permitted in a
Standard-conforming program.  Very specifically.  (A procedure -
function or subroutine - becomes 'active' when it is entered, and
'inactive' when it returns.  It is invalid to for a program to enter a
procedure which is already active.

> 4.  Free form code.  Modern FORTRAN compilers allow for free
>     form entry of code, with similar restrictions that apply
>     to C code with its pre-processor statements (e.g., #define).

Yes, except that spaces are still not significant and so can be put in
or left out at will.  I still think this is 'wrong', as making it
diffcult to parse, and easy to miss errors.  For example, the
following:

    CALL SUBROUTINE (ARG, ARG, ARG)
    CALLSUBROUTINE(ARG,ARG,ARG)
    CAL LSU BRO UTI NE( ARG ,AR G,A RG)

are all valid, and all say precisely the same thing.

>And now a C advantage list.
>
>C Advantages over FORTRAN:
>
> 1.  Data Pointer Types.  FORTRAN apparently still does not
>     have a pointer type.  Underlying argument passing
>     mechanisms in FORTRAN subroutines probably use pointers,
>     but the language definition does not have a data pointer
>     type.  Data pointers conveniently allow referrences to
>     physical memory (useful for microprocessor controllers,
>     perhaps not useful for virtual memory machines) and the
>     "more natural" creation and maintenance of some data
>     structures such as linked lists.

Will probably come to FORTRAN.

> 5.  Dynamic memory allocation.  f77 does not have this, but
>     apparently f9x will have dynamic memory allocation.

On the other hand, FORTRAN allows subroutines/function to have arrays
whose size is not known at compile time.  This makes it easy to write
library stuff without needing dynamic memory (though it's not a
complete substitute.  In original FORTRAN, the array size needed to be
passed as an argument.  (Of course, someone up in the calling chain has
actually got to have the storage defined.)  For example,

    SUBROUTINE FRED (DIM1, DIM2, ARRAY)

    INTEGER ARRAY (DIM1, DIM2)

does the right and useful thing.  (This is something I wish C DID have.)

>FORTRAN Advantages over C:
>
> 3.  Fortran compilers have been around longer and are
>     generally better at optimization than C compilers.

FORTRAN is intrinsically more optimisable than C, for reasons such as
those you give later.  In essence, FORTRAN contains some restrictions
on use which were put in specifically to allow optimizers to hack it
around.

>          (Question:  It's been so long since I've used
>          FORTRAN, but how does the EQUIVELANCE statement
>          affect or not affect aliasing?)

Two ways.  First, (if you have equivalenced things of different types)
it is invalid to reference the variable using any data type other than
the type you used when you last stored into it.  (This helps
optimization, and limits aliasing.)  Second, if two arguments to a
function point to the same 'data chunk' (because they are EQUIVALENCED
higher up) it is invalid for the function (or subroutine, keep
forgetting those) to change the value of either of them.  (As with ever
so many of these restrictions, the compiler can't in general check.  It
is the programmer's responsibility to make sure they have behaved.  If
they haven't, the program is non-conformant, and the behaviour is
undefined.

> 5.  *Natural* array subscripts in C must start with zero, 
>     which for some is counter intuative (of course the C 
>     programmer might ask what is so intuative about starting 
>     with 1 ;-)).  One person mentioned this can cause 
>     optimization problems by defeating alias optimizations in 
>     C, again I don't know if this is the case.  Modern FORTRAN
>     compilers, I'm told, allow for subscripts to start at
>     any value (including negative integer values).  

That is part of the standard.  Notation is B:E where B is the beginning
subscript and E is the end one.  For back compatibility, specifying a
single subscript means 1:number.  It is something else which I wish C
had.  It is nice to be able to define your subscript range to match
whatever bit of the real world you are modelling.  I know it can be
simulated with C macros, but that's a fiddly bother -- just the sort of
thing I pay computers to do.

-- 
Paul Smee, Computing Service, University of Bristol, Bristol BS8 1UD, UK
 P.Smee@bristol.ac.uk - ..!uunet!ukc!bsmail!p.smee - Tel +44 272 303132