(j3.2006) Chaining type-bound procedure references

[Damian Rouson]

On May 2, 2014, at 7:11 AM, Rafik Zurob <rzurob at ca.ibm.com> wrote:

>> 
>> Does C++ require inlining in these scenarios?   

No.   In my copy of a draft of the C++11 standard dated 2010?8-01, section 7.1.2 states

?? The inline specifier indicates to the implementation that inline substitution of the function body at the point of call is to be preferred to the usual function call mechanism. An implementation is not required to perform this inline substitution at the point of call;??

> 
>>> Allowing 
>>> the x%foo()%bar() syntax encourages many references to the same pointer 
> 
>>> function, thus resulting in many temps (and many pointer assignments). 
>>> Even if you forget about inlining, you would expect the compiler to 
>>> attempt to reuse the temp pointers / get rid of multiple calls to foo. 

Aversion to temps is common and I think it is in some ways a holdover from the serial programming days, but I disagree that it should hold sway in a programming language with intrinsic support for parallelism.  It has long been known that functional programs are easier to parallelize and functional programming inherently involves a proliferation of temps.  In the project I?ve mentioned, we compose partial differential equation solvers from purely functional operators.  Producing temps makes it much easier for us to see that procedures can execute asynchronously.  Given that Fortran?s coarray parallel programming model obligates the programmer to handle synchronization, I?ll gladly take the trade-off of creating temps in order to reap the benefit of highly asynchronous execution.  Because all of our operators are PURE and make no use of global state such as module variables, we know that we never need to synchronize in any expression that involves only the use of our user-defined operators. 

>> 
>> Hmm.  I'm not an expert on PURE, but if it allows those types of 
>> access,  then we perhaps need a new declaration (VIRTUOUS?) which 
>> means that only the procedure arguments are accessed.

I agree wholeheartedly!  If some opportunities for optimization were left on the table when PURE was defined, then I hope something will be added to the language to take advantage of those additional opportunities.  VIRTUOUS or maybe FUNCTIONAL?

> Yep, please refer to section 12.7.  Pure really means "no side effects". 
> It doesn't mean "const".
> Several C/C++ compilers have __attribute__(pure) and __attribute__(const) 
> where const corresponds to "virtuous" above.  For example, here it is for 
> GCC:  http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html

The existence of compiler implementations would seem to be a reasonable argument in favor of ?virtuous?.   Would it feasible to add a requirement that only virtuous functions be used in the manner Tom originally proposed?

Damian