(j3.2006) Chaining type-bound procedure references

Bader, Reinhold Reinhold.Bader
Wed Apr 30 16:06:47 EDT 2014


Hello Tom,

in a similar context I've recently noted (on the Intel Software Forum) that ASSOCIATE is your friend. For the situation you describe,

associate (this => obj % method1())
  val = this % method2()
end associate

Perhaps even more so here since it preserves polymorphism, so a TBP will do its proper job (provided the compiler gets it right :-))
The only drawback is that deep nesting of ASSOCIATE blocks may arise.

Cheers
Reinhold

Von: j3-bounces at mailman.j3-fortran.org [mailto:j3-bounces at mailman.j3-fortran.org] Im Auftrag von Tom Clune
Gesendet: Mittwoch, 30. April 2014 20:21
An: fortran standards email list for J3
Betreff: (j3.2006) Chaining type-bound procedure references

On several occasions, and today in particular, I have encountered the situation where it would be clearer (and definitely easier) to implement an algorithm in the following fashion:

val = obj % method1() % method2()

Here method1() returns some object, and method2() is bound to class of that object.   And I realize of course that the language does not (currently) permit anything like this.

I can guess that there are some inherent ambiguities that make my syntax above non starters, though I cannot readily think of what the are.  But what concerns would there be, if any, for either of the following forms:

Option 1:   Parens to force intermediate ("annonymous" object)

val = (obj % method1()) % method2()

Option 2:  Permit a new special operator ("->") that could be overloaded for this purpose:

val = obj % method1() -> method2()

BTW, I would be fine with the constraint that the anonymous object must be CLASS(...), POINTER   if that makes a difference on the implementation side.

For now, my question is simply whether there is something inherently flawed in any attempt to achieve such chaining of operations?  Or would it be more a matter of refinement and priority?   (I'm assuming others have already considered this issue, and would not otherwise assume it could be answered easily/quickly.)

Cheers,

- Tom



Thomas Clune, Ph. D.                                                                 <Thomas.L.Clune at nasa.gov<mailto: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/20140430/dc226cd3/attachment-0001.html 



More information about the J3 mailing list