(j3.2006) Chaining type-bound procedure references

[Tom Clune]

Reinhold,

I want to back off from my conservative statements yesterday.   I am finding a significant category of use cases where the ASSOCIATE construct will definitely help.    I was blinded by the simplicity of my synthetic test cases, but real use cases seem to take enough advantage of the association to amortize the extra lines of code.

Thanks for the suggestion,

- Tom



On Apr 30, 2014, at 5:27 PM, Tom Clune <Thomas.L.Clune at nasa.gov> wrote:

> 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
> 
> 
> 
> 
> 
> 
> _______________________________________________
> 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/20140501/fe387325/attachment-0001.html