Consider adding `pure` or `simple` to PRIF interfaces

[bonachea]

Many PRIF interfaces mimic language intrinsic functions that IIUC are specified by 16.1 as simple.

We should discuss the pros and cons of adding simple/pure decorations to the PRIF interface

[bonachea]

This idea sounds nice in theory.

However in practice it seems likely to greatly increase library implementation burden. Many of the procedures in question (e.g. prif_this_image_no_coarray) fundamentally need to read global library state as part of their normal operation and thus their implementation cannot naturally be declared simple. Even PRIF procedures corresponding to inquiry functions like prif_image_index, prif_image_status, prif_ucobound_no_dim and prif_coshape all actually need to read the library's global team state (to retrieve the current team) as part of their normal implementation (and thus cannot naturally be declared simple). Finally, there are PRIF procedures like prif_allocate, prif_deallocate and prif_notify_wait corresponding to language features that are permitted in a pure context, but the implementation is fundamentally required to modify global library state (and thus cannot naturally be declared pure).

Moreover, the expected practical benefit in production from deploying such a change is vanishingly small. Real compilers are expected to target PRIF procedure calls via a lowering pass that occurs after most high-level analysis and code-motion optimizations have already take place (using a representation of the original multi-image features, and full knowledge of their semantics). So the presence or absence of simple or even pure annotations on the runtime library procedures is not expected to impact optimization within the client code.

The main downside of declining this idea is that it makes it more difficult to deploy straightforward source-to-source transformation of multi-image features to PRIF calls. However there are no current plans to pursue that compilation strategy in production (i.e. outside of unit tests), and if that ever materialized workarounds are still possible.