(j3.2006) Invoking type-bound function using the result of another one

[Van Snyder]

On Fri, 2016-01-08 at 07:27 -0800, Damian Rouson wrote:
> As Tom suggests, I too am very interested in seeing responses to Van's
> question and I would be excited to see the proposed feature gain
> support. 

I looked a bit at this last night.  I would also like to be able to
reference a type-bound function without parentheses if it has no actual
arguments other than its passed-object actual argument, so that I could
write, e.g.

x%f1%f2

instead of

x%f1()%f2()

This is not just aesthetic.  It's useful if f2 started out as a scalar
component, and the requirements got more complicated, requiring it to be
replaced by a function.  Of course, to complete the picture, one needs
updaters so after the requirements change I can just leave

x%f1%f2 = 42

instead of finding all those places and changing them to

call x%f1%setf2 ( 42 )

Maybe these modifications work:

R612 part-ref is part-name [ ( section-subscript-list ) ]
[ image-selector ]
                       or function-reference [ ( section-subscript-list
) ] 

C612a (R612) If part-ref is function-reference and the referenced
function has dummy arguments in addition to its passed-object dummy
argument and its result is an array, function-reference shall be
function-ref-with-args.

R1221 function-reference is function-ref-with-args
                                          or function-ref-sans-args

R1221a function-ref-with-args is procedure-designator
( [ actual-arg-spec-list ] )

R1221b function-ref-sans-args is data-ref % binding-name

Changing part-ref to allow function-reference also allows to compose
subroutine invocation with function reference:

call x%f1%s2 ( a1, a2, a3 )


> 
> Sent from my iPhone
> 
> On Jan 8, 2016, at 5:49 AM, Tom Clune <Thomas.L.Clune at nasa.gov> wrote:
> 
> 
> > Apologies for my C++ accent.
> > 
> > 
> > 
> > I meant ?chaining of invocations of type-bound procedures?.
> > 
> > 
> > > On Jan 8, 2016, at 8:46 AM, Tom Clune <Thomas.L.Clune at nasa.gov>
> > > wrote:
> > > 
> > > 
> > > 
> > > Damian and I have also advocated that the constraints be weakened
> > > to somehow allow such chaining of methods.   If there are
> > > technical reasons why that particular syntax won?t work, then it
> > > seems e could come up with something that is only slightly more
> > > verbose.
> > > 
> > > 
> > > 
> > > 
> > > 
> > > > On Jan 7, 2016, at 9:59 PM, Van Snyder <Van.Snyder at jpl.nasa.gov>
> > > > wrote:
> > > > 
> > > > 
> > > > 
> > > > Given:
> > > > 
> > > > Types T1 and T2 with type-bound functions F1 and F2,
> > > > respectively.
> > > > 
> > > > F1 and F2 have arguments of class T1 and T2 respectively.
> > > > 
> > > > F1 and F2 are also accessible on their own.
> > > > 
> > > > F1 has a result of type T2.
> > > > 
> > > > X1 is a variable of type T1.
> > > > 
> > > > Then I can invoke f2(f1(x1)), but I cannot invoke x1%f1()%f2(),
> > > > i.e.,
> > > > type-bound function composition is prohibited.
> > > > 
> > > > Other than our traditional aversion to selecting components of
> > > > function
> > > > results, or more generally to selecting components of expression
> > > > values,
> > > > was there a technical reason to prohibit this?
> > > > 
> > > > module M
> > > > 
> > > >  type T1
> > > >  contains
> > > >    procedure :: F1
> > > >  end type T1
> > > > 
> > > >  type T2
> > > >  contains
> > > >    procedure :: F2
> > > >  end type T2
> > > > 
> > > > contains
> > > > 
> > > >  type(t2) function F1 ( A )
> > > >    class(t1), intent(in) :: A
> > > >    ...
> > > >  end funciton F1
> > > > 
> > > >  real function F2 ( A )
> > > >    class(t2), intent(in) :: A
> > > >    ...
> > > >  end function H2
> > > > 
> > > > end module M
> > > > 
> > > > program P
> > > > 
> > > >  use M
> > > >  type(t1) :: X1
> > > >  print *, f2(f1(x1))
> > > > ! print *, x1%f1()%f2()        ! Prohibited (why?)
> > > > 
> > > > end program P
> > > > 
> > > > 
> > > > _______________________________________________
> > > > 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>
> > > Software Infrastructure Team Lead
> > > Global Modeling and Assimilation Office, Code 610.1
> > > NASA GSFC 
> > > MS 610.1 B33-C128
> > > Greenbelt, MD 20771
> > > 301-286-4635
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > 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>
> > Software Infrastructure Team Lead
> > Global Modeling and Assimilation Office, Code 610.1
> > NASA GSFC 
> > MS 610.1 B33-C128
> > Greenbelt, MD 20771
> > 301-286-4635
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > _______________________________________________
> > J3 mailing list
> > J3 at mailman.j3-fortran.org
> > http://mailman.j3-fortran.org/mailman/listinfo/j3
> > 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.j3-fortran.org/pipermail/j3/attachments/20160108/de9aad5f/attachment.html