Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!deimos.cis.ksu.edu!unmvax!tut.cis.ohio-state.edu!cs.utexas.edu!sun-barr!sun!aeras!elxsi!beatnix!corbett
From: corbett@beatnix.UUCP (Bob Corbett)
Newsgroups: comp.lang.fortran
Subject: dpANS Fortran 8x
Message-ID: <2716@elxsi.UUCP>
Date: 7 Jun 89 03:08:52 GMT
Sender: news@elxsi.UUCP
Reply-To: corbett@beatnix.UUCP (Bob Corbett)
Distribution: usa
Organization: ELXSI Super Computers, San Jose
Lines: 79

How does one get the most recent ANSI Fortran 8x drafts?  Observer status with
X3J3 does not cut it.  ELXSI has had observer status for the past two years and
has yet to receive a copy of the draft standard.  All observer status buys is
minutes of the X3J3 meetings (often long after they occurred).

The latest draft I have obtained is the March 1989 version.  After reading news
about recent X3J3 meetings on the net, I expected the language to be in even
worse shape than it was at the time of the first public review.  In fact, the
language is much improved over the public review version.  If X3J3 continues to
improve the language at the current rate, it should be ready for the next public
review in just a couple of years.

Pointers are the most significant addition to the language since the public
review.  Pointers made it possible for X3J3 to remove some of the most bizarre
features of the public review version of the language without losing any
functionality.  However, the pointer mechanism described in the March 1989
draft of the standard is itself somewhat bizarre.  It also lacks some of the
functionality usually provided by pointers.

A key difference between pointers in Fortran 8x and pointers in other languages
is that there are no pointer types.  POINTER is an attribute.  For example, a
pointer variable P might be declared as

	                 REAL, POINTER :: P

One problem is that there does not seem to be a way to declare a pointer to a
pointer.  The declaration 

		    REAL, POINTER, POINTER :: P

is illegal.  Pointers to pointers are seldom needed, but it is going to be
painful not to have them on those occasions when they are needed.  On the other
hand, I cannot think of a case where I have needed a pointer to a pointer to a
pointer.

It may be possible to get around the lack of pointers to pointers by declaring
structure types with a single field consisting of a pointer, and then declaring
a pointer to that structure type.  I find this solution distasteful.

Writing the POINTER attribute after the type seems conceptually backward.  I
would prefer a syntax such as

		     POINTER TO, REAL :: P

In the source form that makes blanks significant, the comma could be made
optional.

The committee has chosen to use implicit dereferencing.  For example, if I is
a pointer to an integer, the statement

			     I = I + 1

will increment the value referenced by I rather than I itself.  A pointer
assignment statement must be used to assign to a pointer.  The form of a
pointer assignment statement is

			 pointer => target

Pointers cannot be set to null via assignment.  A NULLIFY statement must be
used instead.  The form of a NULLIFY statement is

		       NULLIFY(pointer-name-list)

I would prefer explicit dereferencing.  The use of pointers frequently
involves aliasing.  Any use of aliasing should be denoted explicitly.
Perhaps the ? character could be used to denote an explicit dereferencing
operator.  I suspect a user would be more likely to guess that the incrementing
assignment shown above involves a potentially dangerous operation if it were
written as

			    ?I = ?I + 1

Note that requiring explicit dereferencing eliminates the need for the
pointer assignement statement and the NULLIFY statement.

					Faithfully yours,
					Bob Corbett
					uunet!elxsi!corbett
					ucbvax!sun!elxsi!corbett