Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!oliveb!ames!ncar!unmvax!brainerd
From: brainerd@unmvax.unm.edu (Walt Brainerd)
Newsgroups: comp.lang.fortran
Subject: Re: Pointer examples and 8x
Keywords: Fortran Pointers, Oxymorons
Message-ID: <168@unmvax.unm.edu>
Date: 23 Jun 89 00:06:56 GMT
References: <638hallidayd@yvax.byu.edu> <12018@pur-ee.UUCP>
Organization: University of New Mexico at Albuquerque
Lines: 41

In article <12018@pur-ee.UUCP>, hankd@pur-ee.UUCP (Hank Dietz) writes:
> In article <638hallidayd@yvax.byu.edu> hallidayd@yvax.byu.edu writes:
> ...
> >      TYPE (NODE), POINTER, INTENT (IN) :: PTR
> >      TYPE (NODE), POINTER :: TRAIL_PTR, TMP_PTR
> ...
> >      TRAIL_PTR => PTR
> >      DO
> >         IF (.NOT. ASSOCIATED (TRAIL_PTR % NEXT)) EXIT
> >         IF (NUMBER <= TRAIL_PTR % NEXT % VALUE) EXIT
> >         TRAIL_PTR => TRAIL_PTR % NEXT      ! Please excuse me if this should
> ...
> 
> THIS is Fortran code?  Well, at least the names are all uppercase. ;-)
> 
I guess I should have headed off this inevitable comment in the first place.
Current Fortran does not have recursion, pointers, or data structures.
That's about all there is in these examples, and it is true, they don't
look much like (current) Fortran.  How could they?  You just can't do
this kind of thing very easily in current Fortran.  Someone
was just saying that IF..ELSE IF..ELSE..END IF doesn't look much like
Fortran (66), but I think most of us are used to it now.
(And, of course, the example could have been done in lowercase!)

An important thing to keep in mind is that the following is (to many people)
the most important addition to Fortran 8x and it sure looks a lot like
Fortran (any version):

      A = B + 2 * C

The catch is that A, B, and C are 100 x 100 arrays.
This is really FORmula TRANSlation, extended to additional kinds
of mathematical objects.

As an aside, though many people treat array processing as the most important
addition now, I think that in 10 years, people will look back and say
that the addition of modules and derived types was at least, if not more,
important (but we need to parameterize the derived types to be useful--
this was removed as a "simplification").

Walt Brainerd   Unicomp, Inc.  brainerd@unmvax.cs.unm.edu