Mon Oct 26 00:22:57 EDT 2015
On Oct 25, 2015, at 8:05 PM, Malcolm Cohen <malcolm at nag-j.co.jp> wrote:
> 1) F2008 prohibits (C1245) the prefix combination of ELEMENTAL and
> RECURSIVE. This is (naturally) missing in F2015. The wording seems
> carefully crafted to not require the NON_RECURSIVE keyword in any function
> definition, so there would not be literal incompatibilities with F2008,
> though it took a while to prove that theorem. A Note in this subclause
> might be helpful in explaining that RECURSIVE is the default, but that a
> procedure could be nonrecursive without specifying NON_RECURSIVE.
> Not so. "Procedures, including elemental procedures, can be invoked
> recursively by default." right there in the Intro.
Yes, I know. That is why I said ?in this subclause?. People normally don?t look in the Intro for explanatory Notes.
> There is no prohibition whatsoever against elemental procedures being
> recursive, which indeed they are by default.
> 2) Note 7.31 in in the F2015 draft 15-007r2 [154:4+] (unchanged from F2008)
> the last sentence:
> "The prohibition against recursion avoids the creation of a new instance of
> a procedure while construction of one is in progress.?
> talks about the prohibition of certain recursive procedures being
> specification functions.
> Sorry, no it is not, and never was. It is a prohibition against recursion
> into the procedure with the specification expression, not a prohibition
I figured out that as well, which is why I said ?certain recursive procedures?, particularly ones that directly or indirectly called a procedure with a declaration that involved a reference to the function.
I?m not arguing that the current normative text is wrong. It seems to have been carefully crafted to get around potential issues. Rather, explanatory Notes would be helpful.
> against recursion of the specification functions. Specification functions
> have been allowed to be recursive since Fortran 2003, it was only Fortran 95
> that forbade that.
> A specification function in an F2008 program that lacked the RECURSIVE
> prefix would hopefully never be called recursively. So, no issue for the
> compiler to check further.
> Not so. A nonrecursive function was not ALLOWED to be called recursively,
> but the compiler needs to do a runtime check if it wants to actually detect
> that (except in the trivial direct recursion case, or unless enough of the
> program can be seen, and is simple enough to analyse, to confirm whether
> recursion might be possible).
> There is no connection here with specification functions. Even
> specification functions that are declared to be NON_RECURSIVE could invoke
> the procedure containing the specification expression without those
> functions violating the nonrecursion rule themselves.
I don?t see how that is possible. If the function calls a procedure that includes a reference (as part of evaluating a specification expression) to the function, then the function is being called recursively. Functions declared NON_RECURSIVE are not allowed to do that.
> However, the implementation of the function might be different in the new
> standard (where recursive is assumed), and the ability to check for correct
> usage of a function that is presumed nonrecursive without having been
> declared NON_RECURSIVE is diminished.
> Not so.
> There would be no difficulty detecting recursion into a procedure while its
> preamble is being executed, should the compiler make the unlikely decision
> to actually detect that particular form of invalid recursion.
> J3 mailing list
> J3 at mailman.j3-fortran.org
Bill Long longb at cray.com
Fortran Technical Support & voice: 651-605-9024
Bioinformatics Software Development fax: 651-605-9142
Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101
More information about the J3