Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!bionet!ames!ncar!unmvax!brainerd
From: brainerd@unmvax.unm.edu (Walt Brainerd)
Newsgroups: comp.lang.fortran
Subject: Re: Pointer examples and 8x
Message-ID: <197@unmvax.unm.edu>
Date: 5 Jul 89 16:54:03 GMT
References: <673hallidayd@yvax.byu.edu>
Organization: University of New Mexico at Albuquerque
Lines: 52

In article <673hallidayd@yvax.byu.edu>, hallidayd@yvax.byu.edu writes:
> >>    TYPE (NODE), POINTER FUNCTION  INSERT (HEAD, NEWNODE) ! I believe this to
> >                ^^^^^^^^^ Can't put this on function line (irregularity?)
> Are we allowed to use (note the double colon)
No, sorry!  My view is that the presence of the type at all is the irregularity
and that the function value should be declared elsewhere.  There is some
movement to have the RESULT variable be declared, not the function name
when the RESULT is present (required for recursive functions), so that
will push things more in the direction of not having declaration stuff
on the FUNCTION line.
> >>       INTEGER            :: NUMBER = NEWNODE % VALUE   ! I believe the syntax
> >                   ^^^^^^^
> >                   , DATA
> >                   ^^^^^^^ Until recently, it was proposed that
> >   you could do this with a DATA attribute; now use the old DATA statement.
> I very much prefer the DATA attribute, rather than the old style DATA
> statement.  I would much rather see the old style DATA statement put on the
> Obsolescent Feature list than give up the DATA attribute.  (Why are we to
> be forced to stick with the old ways of FORTRAN simply because that _was_
> the way things were done in the past---let Fortran *evolve*, allow us to
> use improved methods and constructs, *PLEASE*.  This is directed as much to
> users that complain that _new_ Fortran is not _old_ FORTRAN and therefore
> undesirable, as it is directed at the standards committee.  It contains
> _old_ FORTRAN as a proper subset, and will for at least a decade to come.
> Why is that not enough????)
> 
Because the collected wisdom of X3J3 thinks so and the "public" seems to
get very upset when things are perceived as changing too much.
(Of course, I agree with you.)

Personally, I think the way you did it without the DATA "attribute"
would be just fine (some don't think DATA is an attribute, just the
keyword of a statement used to provide initial values).

> Personally, I could live with the present set of logical operators, defined
> in their present, indeterminate, way (for performance reasons), if we are
> given the addition of true "short circuit" logical `and' and `or' operators

I think you can always get the "short circuit" effect with nested IF statements
and other (minor??) inconveniences, so I don't believe there would be
too much sympathy for this addition, but asking never hurts.

Thanks for trying out some Fortran 8x features.
These little examples bring out lots of interesting points, I think.
It's real tough to do when a) there is no compiler to check it
(only other people who will find your errors for you!), and
b) the proposed standard keeps changing.

I am off tomorrow to WG5 meeting in Ispra, Italy and X3J3 meeting
in Vienna.  It's nasty work, but somebody must do it!
-- 
Walt Brainerd  Unicomp, Inc.  brainerd@unmvax.cs.unm.edu