Re: Pure and internal procedures



On 12/8/2011 7:55 PM, glen herrmannsfeldt wrote:
Michael Trover<mtrover@xxxxxxxxxxxxx> wrote:

(snip, someone wrote)
And I wouldn't call that "internal state". It is rather distinctly
external to the pure procedure - pretty much the opposite of "internal".

(snip)
OK, you don't have to call it an "internal state", but the
functioning of a pure procedure can depend on external data.

When auto-parallelizing some loop the compiler has to decide whether
rearranging the procedure invocations is OK. If all the procedures
invoked are pure than the interfaces of these procedures are enough
information. If one of the procedures is not pure than this serializes
the loop because the invocation of the pure procedures before the impure
invocation cannot be rearranged with the invocation of the pure
procedures after the impure invocation.

Could be. There is the VOLATILE attribute to warn the compiler
that variables might change at unusual times. Without that, I would
expect a compiler not to have to worry about such changes.

The compiler doesn't know whether the impure procedure has
changed the functioning of the pure procedures. That is,
two identical invocations of a pure procedure, one before and
one after an invocation of an impure procedure, have to remain
in that order.

Could be, but maybe only with VOLATILE.

C has volatile, and PL/I has ABNORMAL, but the documentation I
have seen for compliers indicates that they ignore it. In that
case, tough luck if you change something.

-- glen

Well volatile would kill everything. You wouldn't know between invocations what might have changed with the pure procedure.

Think of it this way. This is an example using a function whose interface we know and a code snippet.

Example 1:

interface
function f(x)
real, intent(in):: x
end function
end interface

x = 3.0
y = f(x)
z = f(x)

In this example the function invocations for y and z have to be done. That is the code has to invoke the function twice. The second invocation of f may not return the same value as the first invocation.

Example 2:

interface
pure function f(x)
real, intent(in):: x
end function
end interface

x = 3.0
y = f(x)
z = f(x)

Here the compiler knows, just from the interface, that it only needs to invoke the function once and copy the result to both y and z. That's the power of PURE.

Example 3:

interface
pure function f(x)
real, intent(in):: x
end function
end interface

x = 3.0
y = f(x)
call impure_sub
z = f(x)

This is the example under discussion. Because of the call to impure_sub we are no longer guaranteed that the second function reference for z will yield the same result as the first invocation for y. Therefore f must be invoked twice.

.



Relevant Pages

  • Re: Pure and internal procedures
    ... functioning of a pure procedure can depend on external data. ... the loop because the invocation of the pure procedures before the impure ... interface we know and a code snippet. ... That is the code has to invoke the function twice. ...
    (comp.lang.fortran)
  • Re: Pure and internal procedures
    ... (snip, someone wrote) ... external to the pure procedure - pretty much the opposite of "internal". ... functioning of a pure procedure can depend on external data. ... the loop because the invocation of the pure procedures before the impure ...
    (comp.lang.fortran)