(j3.2006) nonstandard specifics of standard intrinsic generics

[Robert Corbett]

Thank you for taking time to respond to my questions.  I am not
sure how to interpret some of your answers.  If my comments are
below are based on incorrect interpretations, please let me know.

Malcolm Cohen wrote:

> On Thu, 17 Apr 2008 18:16:21 +0900, Robert Corbett <Robert.Corbett at sun.com> wrote:
> 
>>I stated that the implementation provides a nonstandard specific
>>interface for SQRT that takes an INTEGER argument.  That interface
>>conflicts with the specific interface of the generic interface.
>>The characteristics of the nonstandard intrinsic procedure and the
>>procedure in the interface do not differ as specified in 16.2.3.
>>Therefore, constraint C547 is violated.
> 
> No.  If the user provides a specific that would override some
> "specific" of an intrinsic, that intrinsic specific is not part
> of the generic identifier (it is inaccessible by that generic name).

I assume you are using the word "inaccessible" is a different sense
than the sense of its use in the second sentence of the first
paragraph of Section 16.2.3 of Fortran 2003.  I assume that the
sense you intend is that, for the purpose of the conditions set
out in constraint C547 in Section 5.1.2.8 of Fortran 2003, it is
as if those "specific intrinsic procedures" do not exist in the
scoping unit.

If that is the case, is it possible for a program to violate
constraint C547?  Constraint C547 states

      C547 (R503) (R1216)  If the name of a generic intrinsic
           procedure is explicitly declared to have the
           INTRINSIC attribute, and it is also the generic
           name in one or more generic interfaces (12.3.2.1)
           accessible in the same scoping unit, the procedures
           in the interfaces and the specific intrinsic
           procedures shall all be functions or all be
           subroutines, and the characteristics of the
           specific intrinsic procedures and the procedures in
           the interfaces shall differ as specified in 16.2.3.

For example, based on my understanding of what you wrote, the
program

       PROGRAM MAIN
         INTRINSIC SQRT
         INTERFACE SQRT
           REAL FUNCTION MY_SQRT(X)
           END FUNCTION
         END INTERFACE
       END

would not violate constraint C547 because the specific interface
for MY_SQRT in the generic interface would mask the specific
intrinsic procedure with the same characteristics as MY_SQRT.  If
the constraint does not apply in that case, I do not see how it
can ever apply to any code.

You cite the last sentence of Section 16.2.3 as the basis for
your assertion.  That sentence is

      If a generic invocation applies to both a specific
      procedure from an interface and an accessible generic
      intrinsic procedure, it is the specific procedure from
      the interface that is referenced.

I do not see how that sentence applies to the preceding example,
as there are no generic invocations in that code.

> I don't think we say that generic intrinsics are an ordinary set of
> specifics under a single generic (indeed some intrinsics are
> impossible to construct in that way).

You are correct.  The Fortran 90 standard said something like that
in Section 14.1.2.3, but that language has been eliminated from the
Fortran 2003 standard.  Nonetheless, the idea of a set of specifics
seems to be required by the phrase "specific intrinsic procedures"
used in constraint C547.

>>You might have a point.  It might be that the standard allows a
>>processor to add nonstandard specific intrinsic interfaces to
>>generic intrinsics, provided it does not treat cases where they
>>cause conflicts with user generic interfaces as errors.
> 
> This interp was answered back in F90 days, and the answer is that
> the user is allowed to override the intrinsic for the precise reason
> that without that overriding capability it would be impossible to
> portably extend a generic name that was also an intrinsic name.

Yes, it was answered in the Fortran 90 days.  However, Fortran 90
contained nothing like constraint C547.  That constraint is pivotal
to the issue I raised.

> We have not reversed that decision, and the meaning is clear from the
> last sentence of the last paragraph of 16.2.3 (which directly
> contradicts your interpretation of the example above).

The last sentence of Section 16.2.3 applies to generic invocations.
No generic invocations are involved in the application of
constraint C547.  As I read constraint C547, it makes it impossible
for the condition set out in the last sentence of Section 16.2.3
to ever arise.  Your reading of the last sentence of Section 16.2.3
seems to make contraint C547 irrelevant.  One or the other ought to
go.

> BTW, the interp is F90/000083.

The paper in which the constraint that became constraint C547 was
proposed was J3/00-187r1.  I thank Michael Ingrassia for unearthing it.

Bob Corbett