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

[Clune, Thomas L. GSFC-6101]

(1)  I agree that the array case only makes sense in the context of an elemental type-bound procedure.   I don?t see where anything would go wrong if that were permitted, but am quite prepared to learn otherwise after Malcolm has his morning coffee.

(2)  It is true that one cannot do something like what Van requested in C++ (nor in Python/Java so far as I know) which is part of the reason I never pressed for the elemental here.   The approach in those languages is generally to instead use a container class and then add a method to the container that uses an iterator to apply the method to all members.    Fortran of course only has one type of container (Array), and one cannot attach methods to it, so the problem is really a fair bit worse in Fortran.     

With my Fortran container templates, I sometimes do something analogous:

type  :: Foo
contains
   procedure  :: method
end type

< template for FooVector>   ! FooVector is a growable list of Foo objects.

type, extends(FooVector) :: ActsOnAll
contains
   procedure :: method
end type

contains

subroutine method(this)
   class (ActsOnAll) :: this
   type (FooVectorIterator) :: iter

   iter = this%begin()
   do while (iter /= this%end())
	obj => iter%get()
        call obj%method()
       call iter%next()
   end do
end	

With more powerful support for containers this could be considerably simplified.    If the size of the container is fixed at construction, and the objects are not polymorphic, then it would be simpler to have a simple do loop over an array of Foo objects.     But I find that most of the cases where this arises are where one needs a more dynamically sized container and to allow for objects that are extensions of Foo.    It is at that point that the well-tested templates become a more reliable (high-productivity) development tool.

Cheers,

- Tom



> On Jan 17, 2018, at 5:25 PM, Bill Long <longb at cray.com> wrote:
> 
> 
>> On Jan 17, 2018, at 4:02 PM, Van Snyder <Van.Snyder at jpl.nasa.gov> wrote:
>> 
>>> 
>>> 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.
> 
> One option would be to add a Note observing that for the data-ref being an array requires that the TBP be elemental.  That would be consistent with the existing standard. However, it provides different semantics than allowing the dummy to be an array.  I don?t think there is an implementation issue with a passed-object  array dummy being explicit shape, assumed size,  assumed shape, or even assumed rank.  The requirement on it being polymorphic already involves a sufficiently complicated calling convention that all those options are basically already covered. 
> 
> I looked in the C++ 11 standard and found  "	? In the body of a non-static (9.3) member function, the keyword this is a prvalue expression whose value is the address of the object for which the function is called.?.  Sort of suggests there is only one object, rather than an array of them.   Not that we?re restricted to doing exactly what C++ does. 
> 
> 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
> 
> 
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3