(j3.2006) Chaining type-bound procedure references

[Tom Clune]

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

> Hello
> 
> 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.

> 
> val = x%foo()%bar()
> 
> would require a temp pointer
> 
> temp_ptr_dscr => x%foo()
> val = temp_ptr_dscr%bar()
> 
> The most common usage would be for foo to be written as a module procedure 
> and to be accessed via use-association.  i.e. It's going to be in a 
> separate compilation unit and require inter-procedural analysis to inline. 

Perhaps I am naive, but I don't see the connection to inlining.   I am only expecting the method to be invoked, not treated as though it was implemented in the local context.    As things stand, your argument seems to apply to any scenario in which a procedure is called. 

> It's a similar situation to ASSOCIATE, but ASSOCIATE encourages the user 
> to reuse the temp since the temp is really the associate name.  

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.

> 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.

> 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.

Cheers,

- Tom

> 
> Regards
> 
> Rafik
> PS  These concerns are also why I don't like F2008's pointer function refs 
> as vars feature. 
> 
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3

Thomas Clune, Ph. D. 					<Thomas.L.Clune at nasa.gov>
CISTO	Code 606.0
NASA GSFC								301-286-4635
MS 610.8 B33-C128
Greenbelt, MD 20771






-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.j3-fortran.org/pipermail/j3/attachments/20140502/7e39d242/attachment-0001.html