(j3.2006) RECURSIVE

[Malcolm Cohen]

I said:
> "Procedures, including elemental procedures, can be invoked
> recursively by default."  right there in the Intro.

Bill replies:
>Yes, I know.  That is why I said ?in this subclause?.  People normally don?t
>look in the Intro for explanatory Notes.

Contrariwise, the Introduction is *precisely* where they look if they want 
to see what the list of new features is, since That Is Where The List Of New 
Features Is.

Apart from recursive elementals being a new feature, what interesting thing 
is that needs to be said about them?  I would say nothing, especially in 
light of the fact that we could already call recursive functions 
elementally, we just needed an annoying if trivial elemental wrapper to do 
so.

Bill wrote:
> "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.
>>>>

I replied:
> Sorry, no it is not, and never was.  It is a prohibition against recursion
> into the procedure with the specification expression, not a prohibition

Bill replied:
<<<
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.
>>>

It *is* an Explanatory Note.  All it does is explain why the specification 
function is not allowed to invoke the procedure containing the specification 
expression.  I do not see what else there is to explain about that.

And you wrote that the note
  "talks about the prohibition of certain recursive procedures being 
specification functions"

There is no such prohibition, and the Note does not talk about such a 
prohibition!

It is perfectly ok to use all those PURE RECURSIVE functions as 
specification functions almost everywhere.  The
prohibition is against them being *used* in a specific context: that is, not 
from a procedure that they themselves call.  It is not a prohibition against 
them being "specification functions", and indeed they still *are* 
specification functions, by definition, viz
  "A function is a specification function if it is a pure function, is not a 
standard intrinsic function, is not an internal
function, is not a statement function, and does not have a dummy procedure 
argument."

It does not suddenly stop being pure, intrinsic, or non-internal, or 
suddenly become a statement function or gain a dummy procedure argument, 
merely from the appearance of it in a particular specification expression. 
It still fulfils the requirements for being a specification function.  It is 
the specification expression that fails to satisfy the requirements for 
invoking that function.

One might argue that this note is no longer interesting, on the grounds that
(1) anyone who cares about stack frames really should know all this stuff 
without being need to be told, and
(2) it is rationale and not actually useful for understanding what one is 
allowed to do and what the semantics of a Fortran program are.

That is, as a "helpful" Explanatory Note, it is a failure (apparently it has 
wasted Bill's time as well as mine), but that is a horse of a different 
colour.

OTOH, if perhaps it is Bill's point that the Note is more confusing than 
explanatory, or just plain uninteresting or unhelpful, I would not object to 
its removal; I have no strong opinion on that - the note seems ok to me - so 
I am not advocating its removal, just remarking that I do not think I would 
object.

Bill claimed:
> <<<
> 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.
>>>>

I replied:
> 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.

Bill sounds confused:
<<<
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.
>>>>

Well no.

This is not really an important issue, but anyway, what you have missed is 
that it does not get that far, because before it does that it has already 
violated the "No Invocation Of The Procedure Containing The Specification 
Expression" rule.

Once that rule is violated, the program is not in the realm of Fortran any 
more.  So it is not in a position to violate any further rules since, as an 
"already Not Fortran" program, it can do anything it pleases, and the 
processor likewise can do anything it pleases.

Cheers,
-- 
.......................Malcolm.