(j3.2006) types with finalizers defined in finalizer

[Robert Corbett]

Van Snyder wrote:
> On Thu, 2008-08-07 at 23:24 -0700, Robert Corbett wrote:
> 
>>The following module appears to be standard-conforming
>>
>>       MODULE MOD
>>       CONTAINS
>>         SUBROUTINE FINAL(X)
>>           TYPE T
>>             INTEGER I
>>           CONTAINS
>>             FINAL FINAL
>>           END TYPE
>>           TYPE(T) :: X
>>         END SUBROUTINE
>>       END
>>
>>This is the only instance of which I am aware that allows
>>a derived-type with a finalizer to be declared in a
>>context other than the specification part of a module.
>>It requires extra work on the part of the compiler to
>>support a feature that is worthless.  Did I miss a
>>prohibition in the standard?  Does anyone think there is
>>a reason to allow such code in a standard-conforming
>>program?  If so, what is that reason?
>>
>>Bob Corbett
>>_______________________________________________
>>J3 mailing list
>>J3 at j3-fortran.org
>>http://j3-fortran.org/mailman/listinfo/j3
> 
> 
> We didn't take up this question at meeting 185 (we had plenty without
> it).

I understand.  If I had been allowed more time to work on my comments,
you all would have had a lot more to do.

> The example doesn't conform to the standard because the subroutine isn't
> declared to be recursive.

I am sorry to see this response, because you did so well on the
question of the equivalence of circular type definitions.

Why should the subroutine need to be declared recursive?
Section 12.6.2.1 of CD 1539-1 states

     The RECURSIVE prefix-spec shall appear if any
     procedure defined by the subprogram directly or
     indirectly invokes itself or any other procedure
     defined by the subprogram.

Note that "invoking" takes place during the execution of
the program.  It is not a static property of the program.
Because the subroutine in question cannot be invoked, it
cannot be invoked recursively.  Therefore, it does not
need the RECURSIVE prefix-spec.

My request was for language to be added to the standard
specifically to make the example not be standard-conforming.
If there is already such language in the draft standard,
please point it out.

Note that the subroutine

       SUBROUTINE SUBR
         IF (.FALSE.) CALL SUBR
       END

is a standard-conforming subroutine.  Fortran compilers that
cannot compile it are not standard-conforming.  Furthermore,
the program

       SUBROUTINE SUBR
         CALL SUBR
       END

       PROGRAM MAIN
       END

is standard-conforming.  It does not invoke the subroutine
SUBR, and so it does not invoke it recursively.

> I don't think it's necessary to write constraints
> 
> "C4xx (R4xx) If a type definition appears within a subprogram, the
>       final procedure shall not be one defined by that subprogram.
> 
> "C4xx (R4xx) A final subroutine shall not be recursive."

I don't think there needs to be a constraint.  I just don't want
the example I gave to be standard conforming, and possibly show up
in some conformance test suite.

Bob Corbett