(j3.2006) Would there be a technical problem if...

[Van Snyder]

On Wed, 2018-01-17 at 20:47 +0000, Bill Long wrote:
> > On Jan 17, 2018, at 1:56 PM, Van Snyder <Van.Snyder at jpl.nasa.gov> wrote:
> > 
> > 
> > Anyway, I still don't know whether there's a technical problem for the
> > standard or for implementations to allow the passed-object argument to
> > be an array.
> 
> I agree that none of the posts really addressed this. I?m not the
> expert on this stuff, but will try at least some comments. 
> 
> The passed-object dummy argument gets associated with the object that
> is the data-ref in the syntax
> 
>    call data-ref%binding-name
> 
> If the passed-object dummy is an array, then the data-ref would either
> need to be an array or broadcast to each element of the dummy.  Or the
> TBP needs to be elemental.

The section on argument association makes it clear that the
passed-object actual argument becomes associated with the passed-object
dummy argument.  When dealing with non-passed-object arguments, there's
no witter about spreading out a scalar to match an array dummy, which
would be truly bizarre for an assumed-shape dummy.

IMPURE elemental would have sort-of solved my problem.  In my array dump
routine I passed the subscript to the scalar dump routine to be
associated with an optional dummy, for printing.  Not many processors
have IMPURE yet.

> Interestingly in section on procedure reference, the data-ref in the
> call statement is allowed to be an array.  What that means in the case
> of the dummy being a scalar and the procedure not elemental is
> unclear.

Do we need an interp to resolve the discrepancy between type-bound
procedure definition and reference?  I'd prefer that the dummy be
allowed to be an array, and the actual's rank has to match.  I wouldn't
object to requiring the dummy to be assumed shape, but for now I can't
think of a reason to require it.

> I tried a naive example:
> 
> module modu
> 
>   type van
>      integer :: i = 1
>      procedure(van_tbp),pointer :: van_tbp
>   contains
>      procedure :: tbp => van_tbp
>   end type van
> 
> contains
> 
>   subroutine van_tbp(pass_obj)
>     class (van) :: pass_obj
>     print *, "executed tbp", pass_obj%i
>   end subroutine van_tbp
> 
> end module modu
> 
> program test
>   use modu
>   type(van) :: obj_ref, array_ref(10)
> 
>   print *, "call to obj_ref"
>   call obj_ref%tbp
>   print *, "call to array_ref"
>   call array_ref(:)%tbp
> 
> end program test
> 
> With 4 compilers tried, 3 gave errors for mismatched ranks of the actual and dummy arguments.  The 4th accepted the code and printed output as if the dummy were a rank-1 array of size 10.  (The ?1? repeated 10 times.)  This is not too impossible considering that the dummy is declared CLASS and hence would be passed as a pointer to a descriptor. The descriptor contains enough information about rank, bounds, etc. to allow the code to run.   Malcolm or Tom can comment on the conformance of the code, but relying on this working is clearly not portable in practice. 
> 
> If the compiler allowed you to declared the passed-object argument as an array (constraint violation now), then the data-ref in the call could not be a scalar.  That sort of limitation might seem unacceptable to some. 
> 
> Cheers,
> Bill
> 
> 
> Bill Long                                                                       longb at cray.com
> Principal Engineer, Fortran Technical Support &   voice:  651-605-9024
> Bioinformatics Software Development                      fax:  651-605-9143
> Cray Inc./ 2131 Lindau Lane/  Suite 1000/  Bloomington, MN  55425
> 
>