J3/04-294

To: J3
From: Malcolm Cohen
Subject: Canada comment 3, N1588 p298 edit
Date: 4th May 2004
References: N1583, N1588

1. Introduction

The Canadian comment 3 complains about the addition of the optional KIND
arguments to INDEX and LEN, saying that this adversely affects passing
these functions as actual arguments and advocating their removal.  N1588
concurs in there being a problem, but advocates putting additional text in
13.6 to clarify that these new arguments do not affect the specific
(argument) versions of these functions.

/DATA subgroup considers that introducing these optional arguments
introduces no new problem with these functions.  Certainly,  if there is a
problem, it already existed in Fortran 90 and 95; the lack of
interpretation requests on this issue suggests not.

2.Details

The generic versions of AINT and ANINT functions in Fortran 95 already have
an optional KIND argument which determines the kind of the result. However,
this argument is not present in the specific version (otherwise there would
be an incompatibility with Fortran 77).

Similarly, the generic version of INDEX in Fortran 90 has an optional BACK
argument; again, this argument is not (and cannot) be part of the specific
version (for compatibility reasons).

Although these facts can perhaps be deduced from the existing text, some
clarification would improve matters.

3. Discussion

The entry for AINT in the table in 13.6 indicates that the specific version
has arguments only of type default real.  Since the KIND argument is not of
that type, the specific version does not have it.  Similarly for ANINT.

For INDEX, the specific version has arguments only of type default
character, thus excluding BACK which is of type logical and KIND which is
of type integer.

For LEN, again the arguments of the specific are of type character and
therefore again the KIND argument is excluded.

4. Summary

If there is any doubt remaining on these points, since it affects the
interpretation of Fortran 95 programs as well as potential F2003 ones, it
should be resolved via an interpretation request.  This does not seem
necessary at this time as there does not appear to be any discrepancy
between implementations or user expectations on this issue.