(j3.2006) (SC22WG5.5377) [ukfortran] Question on PURE subroutines

[N.M. Maclaren]

On Dec 5 2014, Malcolm Cohen wrote:

> Damian Rouson writes: <<< On a somewhat related note, Tom Clune suggested 
> a while back that there be a "virtuous" attribute that would preclude any 
> access to non-local state. From the standpoint of purely functional 
> programming, I think this would remove a wart that exists with PURE 
> procedures at least in terms of how many people would initially interpret 
> the meaning of PURE.
>>>>
>
> Yes, I've seen this several times before (basically ever since PURE 
> showed up). There are a lot of times that PURE as currently defined is 
> sufficient for parallelism, but equally there are times when they are 
> insufficient - even for pure functions. An attribute like 
> WHITER_THAN_THE_DRIVEN_SNOW would not only improve performance in such 
> cases, they would also give the user a stronger guarantee that he was not 
> inadvertantly shooting himself in the foot.
>
> So far though I've not seen any reasonable spelling for such an attribute 
> (FUNCTIONAL is the best I've noticed so far, and is pretty bad). And so 
> far I've not seen much enthusiasm for Yet Another Attribute with arguably 
> marginal benefits (in my estimation, PURE gets most of the benefits both 
> from the point of view of performance and safety).

Try PRISTINE.

In my estimation, PURE (and even INTENT(IN)) get the benefit only for
simple cases - while they are the vast majority, they are not the ones
which cause parallel programmers weeks or months of debugging and
occasional wrong answers no matter how much they debug their code.

However, I am not sure how feasible it would be to specify a 'truly
pure' property, starting from Fortran, even ignoring the fact that there
are several different and often-confused semantic concepts involved.
For example:

    A function is pure if it doesn't change any data, directly or
indirectly.

    Ditto, but only externally-visible data - this one allows pseudo-
random number generators.

    A function is pure if, when called with the same arguments, it
always has the same effect - e.g. not CLOCK.

The last is NOT the most common one, but IS the one needed for aggressive
optimisation and parallelisation across statements.

Apparently the 'functional programming' people relaxed their definition
very considerably a decade or so back to make it possible to write
realistic programs in a purely functional language.  I have not kept
up with that area, so there may be other semantic definitions as well.


Regards,
Nick.