To: J3                                                     J3/26-220r2
From: Malcolm Cohen
Subject: Correcting and improving PROCEDURE_NAME
Date: 2026-October-28
References: 26-215r2


1. Introduction

The editor's attempts to repair PROCEDURE_NAME while inputting 26-184r1 appear
to be insufficient - there are a couple of problematic cases that are not
correctly handled by the current specification.

The editor also recommended reviewing the first list (CONTEXT absent or false).
This paper attempts to improve the readability and robustness of that list.

Note that this paper does have technical effect, it is not purely editorial.


2. The problematic cases

2.1 Wrong ordering?

The first three cases as specified are:

Case (i) re interface body
Case (ii) Otherwise, if the reference appears within a subprogram,
Case (iii): Otherwise, if the reference appears in the scoping unit of a
            TEMPLATE construct,

Handling subprograms before even considering templates looks wrong, but is
probably okay given that templates have to be in the specification-part of a
main program, module, or template (C1601).

However, an interface body can appear within those specification-parts, which
means there will be a problem there.

Consider:

  MODULE oops
    INTERFACE
      SUBROUTINE sub(a,b)

        TEMPLATE container_te { t }
            USE iso_fortran_env,ONLY:procedure_name
            DEFERRED TYPE :: t
            TYPE t_container
                TYPE(t) value
            END TYPE
            CHARACTER(*),PARAMETER :: where = procedure_name()
        END TEMPLATE

        INSTANTIATE container_te { INTEGER }, integer_container=>t_container,&
                                              integer_container_where=>where

        INSTANTIATE container_te { REAL }, real_container=>t_container,&
                                           real_container_where=>where

        CHARACTER(LEN(integer_container_where)),INTENT(INOUT) :: a
        CHARACTER(LEN(real_container_where)),INTENT(INOUT) :: b

      END SUBROUTINE
    END INTERFACE
  END MODULE

The reference appears within the interface for sub, therefore this defines the
named constants to have the value SUB - it does not get to the template case.

Thus the template case can only activate for a template not defined within an
interface body. C1601 does not prohibit this case yet.

Also, if anyone does the extension of allowing templates in subprograms, there
would also be a problem with subprograms (again, because they precede templates
in the list).

In any case, as templates are not allowed in subprograms, permitting the above
example must have been an oversight. C1601 should be corrected to forbid it.

However, the existing wording is certainly fragile with respect to future
changes. That can and should be improved.


2.2 Wrong specification

Case (iii) is
    "the reference appears in the scoping unit of a TEMPLATE construct"

The "scoping unit" part was inserted by the editor so that nested templates
would be handled correctly, but that does not seem to be completely right.

Consider

    MODULE module

        TEMPLATE one { n }
            USE iso_fortran_env
            DEFERRED INTEGER, PARAMETER :: n
            CHARACTER(*),PARAMETER :: one_name = procedure_name()
        END TEMPLATE

        TEMPLATE two { n }
            USE iso_fortran_env
            DEFERRED INTEGER, PARAMETER :: n
            TYPE t
                REAL :: v(n) = 0.0
                CHARACTER(len(procedure_name())) :: name = procedure_name()
            END TYPE
            TYPE(t),PARAMETER,PRIVATE :: ugh
            CHARACTER(*),PARAMETER :: two_name = ugh%name
        END TEMPLATE
    END MODULE

    PROGRAM test
        USE module
        INSTANTIATE one { 17 }
        INSTANTIATE two { 13 }
        PRINT *,one_name            ! prints "ONE"
        PRINT *,two_name            ! prints "MODULE"
    END PROGRAM

As the reference to procedure_name in template "two" does not appear in the
scoping unit of a template (it appears in the scoping unit of a derived type),
the result is rather strange. Especially strange because otherwise, being in
the scoping unit of a derived type has no effect on procedure_name.

If we want the reference to procedure_name in template two to return "TWO",
that case should be changed to "the specification part of a template", and to
handle nested templates, it should be "the name of the innermost template".


3. Word smithing

Cases (i), (ii), and (iii) refer to things that can be nested in other things,
and in all cases we should prefer the name of the "innermost such thing".
That suggests combining those three cases into a single case. This also gets
rid of the ordering glitches without over-complicating the text.

Cases (iv), (v), and (vi) refer to things that cannot be nested. These could
also be combined into a single case.


4. Edits to N2258

[396:12] 16.1.1 Syntax for the TEMPLATE construct,
         after R1601 template-construct,
         in C1601,
         append new sentence
   "A template-construct shall not appear within an interface-body."

[550:17-23] 17.10.2.29 PROCEDURE_NAME, p5 Result Value,
            replace the existing cases (i) to (iii) with:
   "Case (i): If the reference appears within an interface-body, subprogram, or
              TEMPLATE construct, the result value is the name of the innermost
              such syntactic unit. The name of an interface-body is that of the
              procedure whose interface is being declared. The name of a
              generic subprogram is the generic name."
{We have not previously used the phrase "syntactic unit", but it seems to be
 the best way to describe those three things.}

[550:24-29] Replace existing cases (iv) to (vi) with:
   "Case (ii): Otherwise if the reference appears in a named program unit,
               unnamed main program, or unnamed block data program unit, the
               result has a value equal to the name of the program unit,
               'MAIN PROGRAM', or 'BLOCK DATA', respectively."
{The existing text is readable, but this is shorter.}

===END===