(j3.2006) Questions about 7.1.4p2

[Malcolm Cohen]

<<<
There is a list in 7.1.4p2:

o  the evaluation of a function reference shall neither affect nor be
   affected by the evaluation of any other entity within the statement;

o  if a function reference causes definition or undefinition of an
   actual argument of the function, that argument or any associated
   entities shall not appear elsewhere in the same statement.

It seems that the second item is covered by the first one.  Is there
something I've missed here?
>>>

Apparently, since they are quite different.

<<<
If the second isn't covered by the first, the second should include
change to pointer association status, and maybe allocation status.
>>>

Changes to pointer association status or allocation state cause the variable 
to become defined or undefined, so they are already covered.

<<<
Perhaps another list item is necessary also:

o  if a function reference causes definition, undefinition, or change
   of the allocation status or pointer association status of a global
   variable or a variable accessed by host or use association, neither
   that variable nor any associated entities shall appear elsewhere in
   the same statement.
>>>

I do not think we want to introduce this new requirement, which would 
apparently introduce an incompatibility with every Fortran standard since 
1990.

<<<
If you have

a(i:j) = f(x)

and f accesses i or j by host or use association, you probably either
don't want f to change them,
>>>

That is already prohibited by the very first item you quoted.  If evaluating 
F(X) causes I to change, that is most definitely affecting the evaluation of 
I.

<<<
or you don't want to use them in the LHS of
the assignment statement.  Even worse, what if f accesses a by host or
use association, and it's allocatable or a pointer, and f reallocates
it?
>>>

Why is this "worse"?  Anyway, it seems to be allowed, or rather, I could not 
immediately find a prohibition against it.

Assuming for the time being that there is no prohibition against it, this 
feature goes back to Fortran 90 so if it is allowed there, we should 
definitely leave it alone unless it is actually broken - it is rather too 
late to be adding restrictions to Fortran 90 allocatable arrays and pointer 
variables, even if it might have been a good idea at the time.

<<<
But then, in

b = g(x)

what if b is polymorphic or allocatable and gets reallocated because the
dynamic type, a length parameter, or extent, are not the same as the
result of g(x).  Is there a conflict here?
>>>

Probably not.

<<<
  Is it the function
reference, or evaluation of the function reference, that results in
changing b?
>>>

I do not understand what you are trying to ask here, since in the context of 
"causing" b to change, there is no difference between a function reference 
and the evaluation thereof.

Back to the serious question.  In general, g(x) is going to need to be 
evaluated to find out what its dynamic type, type parameter values and shape 
are, so you cannot compare them before evaluating g(x) but only afterwards. 
So if g(x) causes b to be reallocated with different type, type parameter 
values or shape, it must be the new attributes that are relevant.

<<<
Perhaps the second list item, and the proposed additional one, should
have "evaluation of a function reference" instead of simply "a function
reference".
>>>

I do not think so.  A function reference can only "cause" something to 
happen if it is executed (i.e. evaluated), so in that context it is a 
distinction without a difference.

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