(j3.2006) Chaining type-bound procedure references

[Rafik Zurob]

Hi Tom

>> While I use this feature extensively in my C++ programs, I (personally) 

>> strongly oppose it in today's Fortran.  C++ can get away with 
>> x.foo().bar() because inlining is part of the language and the 
definitions 
>> of inline member functions appear in the same translation unit as the 
>> call.  That's not the case in Fortran. 
> 
> Does C++ require inlining in these scenarios?   Many of the examples
> I've seen using iterators, would have bar() be a rather involved 
> function that would be very awkward to inline.

Sorry, I wasn't clear.  I don't want to inline bar().  I would like to 
inline foo().  It's not a language requirement, but it's allowed and is 
often done for small functions.  My point is that C++ makes it easy to 
inline foo (if it makes sense to inline it).  Fortran does not.  If one 
uses a coding style that encourages a lot of calls to small functions and 
the functions are not inlined, there will be significant overhead.

> If anyone could provide a short explanation as to how Reinhold's 
> example in this thread actually works, I would appreciate it.  I've 
> always understood the ASSOCIATE construct to be purely textual 
> replacement - not involving any actual entities.  But that 
> understanding is clearly inadequate to explain this scenario.

There are several ways to implement ASSOCIATE.  Textual substitution is 
not good enough if the selector has a side effect.  One could implement 
associate as a subroutine call where the selector is the actual argument 
and the associate name is the dummy argument, but that's somewhat of an 
overkill.  The way we implement it is using temps.  If the selector is 
definable, the associate name is like a Fortran pointer to the selector. 
If the selector is not definable then we just use a regular temp.  There 
are refinements beyond definability, but that's the general idea of how at 
least our compiler does it.

>> 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. 
> 
> I'm not sure that this is an argument against the feature.   More a 
> cautionary note to the implementors.  This will hardly be the only 
> occasion in which many compilers fail to extract an invariant for 
> optimization purposes.    And if they can't in some performance 
> critical region, one still has the more verbose options.

I respectfully disagree.  If we can help it, we shouldn't add features 
that are hard to optimize and then leave it to the implementers to deal 
with it.  Some of the things that make Fortran a good language is that it 
keeps ease of optimization in mind.  For example, requiring the TARGET 
attribute for pointer targets.  IMHO, ASSOCIATE is a good middle ground, 
although I do understand the verbosity argument.

>> That's not easy, even if you mandate that pointer functions like foo 
must 
>> be pure.  Note that Fortran has the notion of pure, but does not have 
the 
>> notion of const functions that are pure and don't read any 
use-associated 
>> or host-associated data.
> 
> 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.

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

Regards

Rafik