To: J3 J3/17-158r2
From: John Donners & Eric Lorenz & Stefano Zaghi & Steve Lionel
Subject: Assumed-rank array bounds
Date: 2017 June 27
Discussion:
-----------
Dear Committee members,
We would like to thank you for your efforts to bring the Fortran
standard forward with many new functionalities, while keeping the
strengths of the language. We would like to discuss one particular
feature that was introduced in the draft Fortran 2015 language standard:
the bounds of ordinary, assumed-rank arrays.
TS 29113 introduces the notion of the assumed rank array in section
5.2 Section 6.3 defines that the bounds of the assumed rank array
are implied from the actual argument for allocatable and pointer arrays.
The Draft Fortran 2015 standard modifies this behaviour in section
12.5.2.4 ('Ordinary dummy variables'), clause 15:
"An actual argument of any rank may correspond to an assumed-rank
dummy argument. The rank and shape of the dummy argument are the rank
and shape of the corresponding actual argument. If the rank is nonzero,
the lower and upper bounds of the dummy argument are those that
would be given by the intrinsic functions LBOUND and UBOUND respectively
if applied to the actual argument, except that when the actual argument
is assumed-size, the upper bound of the last dimension of the dummy
argument is 2 less than the lower bound of that dimension."
So the bounds of ordinary dummy variables are also implied from their
actual argument, not only for allocatable or pointer arrays. We plea to
keep this functionality in the final Fortran 2015 standard.
A defining feature of fortran is that the definition of bounds belong
to the array. It underlines its use in scientific computing where an
array index always has an actual meaning and, since that meaning is not
always counted starting from 0 or 1, is more than just a pointer to an
element. This frees the programmer from always explicitly translating his
meaningful index to a pointer index (mentally and in the code itself).
So this nice feature should be further solidified in the new standard by
passing the bounds to the dummy assumed-rank array.
We think that this functionality is important and that it doesn't
interfere with other dummy array types.
Many Fortran applications use the variable lower bound of an array, but
need to use different methods to pass these bounds between routines:
-define the bounds in a module, common block or include file
-define the array in a module, common block or include file
-define the array as member of a user-defined structure
-bounds remapping
Bounds remapping is not applicable to assumed-rank arrays. The
other options require some application-specific knowledge in a subroutine
to use the full power of the Fortran array syntax.
The definition of ordinary, assumed-rank dummy arrays as described in
the current draft would allow for independent libraries that use the
full power of Fortran arrays.
The assumed-rank array can be combined with the generic TYPE(*) to allow
for fully general arguments. A single routine can handle any basic type
of any rank, removing the need for an interface of routines that do the
same, except for their different argument types and ranks. The generic
part of the routine will have access to little information about the
actual argument, in which case the array bounds can be quite useful.
Since the actual data of the assumed-rank array can only be indexed
through explicit SELECT RANK (if adopted) and SELECT TYPE statements,
there is little cause for confusion. The programmer has to use
the UBOUND and LBOUND functions to access the array bounds of an
assumed-rank dummy argument in the generic part of the code (outside
the SELECT .. statements). This is quite different from other dummy
arrays, where the programmer can explicitly write out the indices.
An alternative could be the introduction of a new characteristic for
dummy arrays, which would indicate that the dummy assumes the bounds
of the actual argument. This would have some advantages:
-it can also be introduced for assumed-rank, assumed-shape and
assumed-size arrays
-codes that would already use assumed-rank arrays would not be broken
-programmers can choose when to assume bounds
Our conclusion is that it would be a powerful addition to the language,
where independent libraries can be written in Fortran, without losing
a defining feature of the language.
With regards,
John Donners - Senior Consultant - Computing Center SURFsara, Amsterdam
Eric Lorenz - CEO - Electric Ant Lab, Amsterdam
Stefano Zaghi - Aerospace Engineer - National Research Council of Italy
PS: this letter has also been discussed on the newsgroup
comp.lang.fortran, see
https://groups.google.com/forum/#!topic/comp.lang.fortran/gNJGmqn3I9s
J3 Response
-----------
There are some misconceptions in your description of this "feature".
When the text says that the shape of the dummy argument is
taken from the actual argument, that does not mean the lower and
upper bounds! The shape of an array is the list of its extents - that
is, the number of elements in each dimension.
For non-pointer, non-allocatable assumed-rank dummy arguments, the
lower bound is always 1 and the upper bound, except for assumed-size
actual arguments, is always the extent. This allows for consistent
treatment of actual arguments that are array slices, which have no
intrinsic lower and upper bounds. Note that the text you cite references
LBOUND and UBOUND which describe this behavior.
The text you quote from the standard, in fact, reveals an error in
translating the functionality described in TS29113 to edits for the
new standard. It was not intended that dummy arguments associated with
assumed-size actual arguments assumed any particular bounds. A
literal reading of the J3/17-007r1 text would result in such dummy
arguments having an empty last dimension. N2125 comment GB029 addresses
this error, and paper J3/17-170 has been written to supply a correction.
You have also suggested a new feature that would explicitly provide for
assuming the bounds of the actual argument. Overlooking for now that
this request is out-of-scope at this point in the standardization
process, the concept was extensively discussed during development of
Fortran 90, but it was rejected largely due to it not being able to
consistently handle the case of array slice arguments.
==END==