(j3.2006) Questions about passed-object dummy argument

[Van Snyder]

I have a rank-one list of interpolation coefficients from a field that
might be of rank one, two, or three, onto a rank-one path.  The list of
coefficients is the same size as the path.

The field might be value on a two-dimensional grid of horizontal X
vertical coordinates, while the path is a one-dimensional path on which
the radiative-transfer equation is integrated, in which case each point
on the path can depend upon at most four points in the field (assuming
multilinear interpolation).

Or the field might have a two-dimensional quadrilateral horizontal grid
and a vertical grid, in which case each point on the path can depend
upon at most eight points in the field.

Or the field might have a two-dimensional triangular horizontal grid and
a vertical grid, in which case each point on the path can depend upon at
most six points in the field.

Or in addition to the various kinds of geometric grids, the
interpolation might depend upon frequency.

Etc.  So there's a different type for the coefficients for each case,
with each type being an extension of an abstract base type.

I'd like to bind an interpolator to each type.

I'd like the coefficient arrays to be polymorphic of the abstract base
type, so that I can invoke an interpolator using

  call eta%interoplate ( field, path )

with guts something like this (slightly different for each type of eta
and each rank of field):

    do i = 1, size(eta)
      path(i) = sum( [ ( eta(i)%v(j)%v * &
                       & field(eta(i)%v(j)%y,field(eta(i)%v(j)%x), &
                       & j = 1, eta(i)%n ) ] )
    end do

and the invoked interpolator depending upon the dynamic type of eta.

The problem is that eta is not a scalar, and the passed-object dummy
argument is required to be a scalar by C761 (in 16-007r2).  But C1536
says that if <data-ref> is an array, the referenced type-bound procedure
shall have the PASS attribute, which seems to allow a non-scalar
passed-object dummy argument.

First question: What's the point of C1536 if C761 requires the
passed-object dummy argument to be a scalar?  It arose from F03/0016,
where the question was about elemental procedures.  The discussion
included "If the type-bound procedure does not have both the PASS
and ELEMENTAL attributes, the invoking object shall be scalar."  But the
constraint is the other way around, and doesn't mention elementality.

Second question: Is it necessary for C1536 to require the PASS
attribute, or should it instead prohibit the NOPASS attribute?  The link
for "PASS attribute" in C1536 leads to 7.5.4.5, which describes the
passed-object dummy argument, but doesn't mention the PASS attribute.
In fact, the only place that "PASS attribute" appears as such is in
C1536 (and in the index).  Just guessing, but since the syntax term in
R752 is <binding-attr>, it appears that "PASS attribute" means that
<binding-attr> is PASS [ (<arg-name>) ], i.e., PASS is required
explicitly to appear in <type-bound-proc-binding>.  It would be helpful
if C1536 required the invoked procedure to be elemental, rather than
requiring the reader to prove a theorem using C761 (which is eight
clauses distant).

Third question: Why was it necessary to require the passed-object dummy
argument to be a scalar?

A processor could certainly check the rank of <data-ref> against the
rank of the passed-object dummy argument, even if generic resolution is
involved.  We know how to do generic resolution when both elemental and
nonelemental specific procedures are involved.  I'd like to understand
this.

In the illustrated case, an elemental procedure would work, if only an
elemental procedure were allowed to have an array argument (the field,
in this case) that isn't used elementally.  But if the coefficient array
includes the subscript of the path array to which it applies, rather
than the positions in the coefficient and path arrays corresponding,
even that kind of more-liberal elemental procedure doesn't work.

Rather than using a type-bound procedure, it appears I need to do

  select type ( eta )
  type is ( value-1D-list_t )
    call interpolate ( field, eta, path )
  type is ( value_QTM_1d_list_t )
    call interpolate ( field, eta, path )
! etc.
  end select

where "interpolate" is generic.

Is there a way around this?

Fourth question: Could we remove "scalar" from C761, and replace C1536
with something like the following?

  C1536 (R1523) If the referenced procedure is elemental the specific
        binding shall specify a passed-object dummy argument.

or if necessary

  C1536 (R1523) If the referenced procedure is elemental and <data-ref>
                is an array, the specific binding shall specify a
                passed-object dummy argument.