(j3.2006) Irksome not to be able to invoke type-bound function on an expression

[Van Snyder]

Fortran programmers had figured this out fifty years ago, with respect
to subscripts.  A subscripted array reference is just a function
reference that the processor knows how to write and (hopefully) inline.

It also isn't vastly different from using a function reference as an
actual argument to another function.  Fortran programmers worked out
these performance implications half a century ago also.

I suggested I might want to do

  s = v%f1()%f2()

This isn't different from

  s = f2(f1(v))

On Tue, 2016-09-27 at 00:06 -0400, Rafik Zurob wrote:
> One thing to watch out for with v%geod()%h_geod is performance if you have 
> multiple instances of it.  C++ gets away with it because you typically 
> #include your inlinable member function definitions into the same 
> translation unit and the compiler frontend or low-opt backend inlines 
> them.  Fortran type-bound procedures will typically be in a separate 
> compilation unit (e.g. a module) and typically will not be inlined unless 
> you enable expensive whole program optimization / link time optimization. 
> If you're only accessing one component of v%geod(), and accessing it only 
> once, you probably don't care.  But if you're accessing multiple 
> components or bindings of it, the explicit temp is a much better choice 
> that's not dependent on compiler optimization.  Also, note that if you're 
> using virtual or non-const (*) functions, the optimizer might not be able 
> to inline, and you might call v%geod() every time it appears in the 
> source.  The temp is an even better approach if v%geod() is expensive.
> 
> Regards
> 
> Rafik
> (*) const in the C++ sense.  I think we had a proposal for adding a 
> "virtuous" procedure prefix with the same meaning.  Pure functions can 
> still access global data.  So you can't replace
> x = pure_foo()
> y = pure_foo()
> with
> x = pure_foo()
> y = x
> without seeing the definition of pure_foo.  Similarly, if you have:
> x = v%geod()%h_geod
> y = v%geod()%h_geod
> and v%geod() is non-virtuous, you'd still execute the code in v%geod() 
> twice.
> 
> j3-bounces at mailman.j3-fortran.org wrote on 26/09/2016 09:31:53 PM:
> 
> > From: Van Snyder <Van.Snyder at jpl.nasa.gov>
> > To: j3 <j3 at j3-fortran.org>
> > Date: 26/09/2016 09:32 PM
> > Subject: (j3.2006) Irksome not to be able to invoke type-bound 
> > function on an expression
> > Sent by: j3-bounces at mailman.j3-fortran.org
> > 
> > I have a type ECR_t that represents Earth-centered-rotating Cartesian
> > coordinates as 3-vectors.  It has type-bound functions and operators to
> > add, subtract, scale, compute 2-norm, and other stuff.
> > 
> > I'd like to compute
> > 
> >   s = ( ( myP + myH * myP%grad_geoid() - line(1) )%norm2()
> > 
> > but this is prohibited, so I need either to export norm2() as an
> > ordinary (not type-bound) function and use
> > 
> >   s = norm2( myP + myH * myP%grad_geoid() - line(1) )
> > 
> > or
> > 
> >   temp = ( ( myP + myH * myP%grad_geoid() - line(1) )
> >   s = temp%norm2()
> > 
> > One particularly important case is function composition.  I'd like to
> > use something like
> > 
> >   s = a%f1()%f2()
> > 
> > Is there a good reason we can't eventually allow to invoke a type-bound
> > function using an expression, and in particular using the result of
> > another type-bound function?
> > 
> > A related question is whether we can eventually select components from a
> > function result (or more general expression).  I have a function Geod()
> > bound to ECR_t that computes 3-dimensional geodetic coordinates
> > (longitude, geodetic latitude, and geodetic height), from
> > Earth-centered-rotating Cartesian coordinates.  The iteration (Either
> > Bowring's or Fukushima's) that does this necessarily computes both
> > geodetic latitude and geodetic height.  But sometimes all I want is
> > geodetic latitude.  My type H_V_Geod that represents 3-dimensional
> > geodetic coordinates is an extension of the one H_Geod that represents
> > only longitude and geodetic latitude.
> > 
> > If I have
> > 
> >   type(ECR_t) :: V
> >   type(H_Geod) :: Geod
> > 
> > I can't get the geodetic surface components (longitude and geodetic
> > latitude) of V using
> > 
> >   geod = v%geod()%h_geod
> > 
> > I need something like
> > 
> >   type(H_V_Geod) :: Temp
> >   temp = v%geod()
> >   geod = temp%h_geod
> > 
> > Is there a good reason we can't eventually allow to select a component
> > of an expression?
> > 
> > 
> > _______________________________________________
> > J3 mailing list
> > J3 at mailman.j3-fortran.org
> > http://mailman.j3-fortran.org/mailman/listinfo/j3
> > 
> 
> 
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3