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==