Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!psuvax1!psuvm.bitnet!psuvmxa!cunyvm!byuvax!hallidayd
From: hallidayd@yvax.byu.edu
Newsgroups: comp.lang.fortran
Subject: Re: Pointer examples and 8x
Message-ID: <662hallidayd@yvax.byu.edu>
Date: 28 Jun 89 05:14:29 GMT
Lines: 98

Referring to Walt Brainerd's (brainerd@unmvax.unm.edu) article (message
<168@unmvax.unm.edu>)

>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

I suggest that if the committee really wants to "simplify" Fortran 8x that
they could remove the TYPE(user data type name) construct in favor of
allowing user data types to be used as if they were intrinsic data types in
declaration statements of the form

data_type_name [,attribute[,...]] :: variable_identifier_list

The only need for the TYPE(user data type name) construct is to avoid
ambiguities when using user data types in the _old_ FORTRAN style variable
declaration statements.  Since user data types are _new_, why not restrict
their use to the _new_ form of variable declaration statement where no
possibility for ambiguity may arise?

Another possible "simplification" that seams reasonable (to me) is to
change the POINTER attribute to ALLOCATABLE (after all, the present
proposal uses the ALLOCATE function in much the same way as for ALLOCATABLE
arrays---only the inapplicable subscript range information is missing).
This then (possibly) solves the contention that Fortran POINTERS are "not
really pointers, and will cause confusion for people coming from other
languages with pointers", while giving us the recursive data structures
that are needed.  It also changes ALLOCATABLE arrays from a special class
to being a member of the class of ALLOCATABLE data structures (after all,
arrays are just a special form of data structure).  (It still retains the
ability to reference array sections using the => operator so long as the
referenced array section has the same number of free subscripts as the
ALLOCATABLE array that references it.  We can, rather naturally, limit such
array aliasing to arrays declared with empty subscript ranges (as are used
only for ALLOCATABLE arrays) if we have the ALIAS/IDENTIFY pair, and thus
no need for aliasing arbitrary array sections by other methods.)

Furthermore, if the USE clause is allowed within MODULEs (as it should be,
providing programmers with an inheritance mechanism, which is sorely needed
when the programmer does not have access to the source code) then why do we
need INCLUDE (a poor man's implementation of MODULEs, such as in C)?  Yes,
it can be used to include a set of comments that are common to several
program units, such as copyright notices (though these should, probably, be
actually included in the source files), that will then be displayed in the
compiler listing, but are such uses enough to justify the need for the
INCLUDE?  (Admittedly, INCLUDE is not very expensive for compiler writers
to provide, but it is a "simplification" in the sense that the standard
need not contain the specifications for such a statement).

(The following is grousing over one of the source of the "simplification"
thrust, as I perceive it.)

I don't know if many readers can tell from my postings, but I don't have
much sympathy for the complaints of large companies with widely distributed
FORTRAN compilers that want Fortran 8x to be simply a reflection of their
present compilers (see the Digital Review article that Curtis E Reid
(CEReid@cup.portal.com) commented on in message <19553@cup.portal.com>).
True, we need the input of compiler writers to help us retain connection
with reality, but when their comments are simply complaining about how much
work they will have to do to provide the users with sufficiently powerful
features (which they had not already provided) I take it with a grain of
salt.  A compiler is written once (though maintained over a hopefully long
period of time) while it is used thousands of times by programmers.  Where
should the bulk of the labor reside---the compiler/language, providing
powerful utilities to the programmers using it, or the programmers, having
to work around absent features in the language/compiler?

Personally, I am incensed when a compiler distributer claims they know
exactly what my needs are, and tells me what I do and don't need.  Some of
these companies claim to be providing everything the scientific community
needs (probably justifying this position on the grounds that a large share
of the scientific community uses their compilers and/or hardware).  While
it is true that a great deal of finite difference and finite element code
only needs the array structures of FORTRAN (with some need for dynamically
allocatable arrays so routines need not be rewritten whenever larger arrays
are needed), there are many problems for which old FORTRAN has been
*TOTALLY* inadequate (see for example the article ``Computers in physics:
an overview'' in _Physics Today_, May 1983, Vol. 36 No. 5, by Donald R.
Hamann, pp. 24--33, particularly the subsection ``FORTRAN a curse?'' of the
``Software'' section, pages 29--31).  If the Fortran language proposal is
not "simplified" to death, it may actually win back some of us ``wayward''
scientist for whom Fortran is truly a ``curse''.  (I would use Ada, except
Ada compilers are not widely available, and I hope to make a contribution
to the future of Fortran by standing up for my convictions.)

(Enough grousing from this disgruntled physicist.  Go back to your old
ways, if you wish.)

   _____________________________________
  / David Halliday                      \
  |                                     |
  | Internet:    hallidayd@yvax.byu.edu |
  | BITNET:      hallidayd@byuvax       |
  | Us Mail:     BYU Physics Department |
  |              296 ESC                |
  |              Provo, UT  84602       |
  \_____________________________________/