(j3.2006) Chaining type-bound procedure references

Tom Clune Thomas.L.Clune
Wed Apr 30 17:27:00 EDT 2014


Hi Renhold,

Interesting.

I see some merit with this approach, but it still seems very verbose from the users perspective.  It does avoid the declaration of a variable for the intermediate step, but requires 3 lines and something that still looks like 2 steps.    Nesting is not an issue in the scenarios I have in mind.

Your suggestion would gain strength if I needed multiple quantities inside the block to exploit the intermediate expression, but I don't think I'll see much of that.   In fact even when there would be a sequence of similar actions it would probably look like:

val1 = this%find('mass')%get()
val2 = this%find('length')%get() 
?

Cheers,

- Tom




On Apr 30, 2014, at 4:06 PM, "Bader, Reinhold" <Reinhold.Bader at lrz.de> wrote:

> 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>
> CISTO Code 606.0
> NASA GSFC                                                                                                             301-286-4635
> MS 610.8 B33-C128
> Greenbelt, MD 20771
>  
>  
>  
>  
> 
>  
> _______________________________________________
> 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/20140430/6faa6054/attachment-0001.html 



More information about the J3 mailing list