To: J3                                                     J3/23-217
From: Brad Richardson
Subject: Usable Polymorphism in Coarrays
Date: 2023-September-27

1. Introduction
===============

At present there constraints preventing the (effective) use of
polymorphic entities within a coarray. This eliminates the possibility
of using patterns or techniques involving polymorphism in many areas
of parallel or distributed computing. This paper suggests adding this
as a work item for F202Y, along with a possible avenue to enabling it.

2. A Possible Relaxation to Allow Polymorphic Entities in Coarrays
==================================================================

Currently the following constraints prevent the use of polymorphism in
coarrays.

> C917 (R911) Except as an actual argument to an intrinsic inquiry
              function or as the designator in a type parameter
              inquiry, a data-ref shall not be a coindexed object that
              has a polymorphic allocatable potential subobject
              component.

> C918 Except as an actual argument to an intrinsic inquiry function or
       as the designator in a type parameter inquiry, if the rightmost
       part-ref is polymorphic, no other part-ref shall be coindexed.

> C1528 (R1522) A data-ref shall not be a polymorphic subobject of a
                coindexed object.

> Note 1: When resolving type-bound procedure references, constraints on
        the use of coindexed objects ensure that the coindexed object
        (on the remote image) has the same dynamic type as the
        corresponding object on the local image. Thus a processor can
        resolve the type-bound procedure using the coarray variable on
        its own image and pass the coindexed object as the actual argument.

It has also been suggested that defining an entity that has polymorphic
components on a remote image may require (re)allocation of those
components. Since all known technologies used to implement the parallel
features do not allow allocation of memory on a remote image, the
constraints are intended to prevent such use.

It may be possible and desirable to reference polymorphic entities on
a remote image. The following modifications to the above constraints
may be sufficient to achieve this.

> C917 (R911) If data-ref is a coindexed object that has a polymorphic
              allocatable potential subobject component it shall not
              appear in a variable definition context.

> C918 If the rightmost part-ref is polymorphic and any other part-ref
       is coindexed, the data-ref shall not appear in a variable
       definition context.

Delete C1528 and Note 1.

3. A Real World Use Case
========================

In designing an extensible framework for asynchronous task execution,
a need for a payload type to communicate inputs and outputs to tasks
becomes apparent. An example of such a framework can be found in the
following GitHub repository.

https://github.com/sourceryinstitute/FEATS

At present, the payload consists of an array of integers as its
component. Thus a user of the framework must devise a way to serialize
and deserialize any data they wish to communicate between tasks into
such a representation. If the payload component could be unlimited
polymorphic, the serialization would just require appropriate allocation
of the payload component, and deserialization would require only a
SELECT TYPE construct.

A simpler example that illustrates the desired capability is shown below.

program main
    implicit none

    type, abstract :: parent
    end type

    type, extends(parent) :: child
       character(len=:), allocatable :: message
    end type

    type :: wrapper
      class(parent), allocatable :: item
    end type

    type(wrapper) :: coarray[*]

    if (this_image() == 1) then
      coarray%item = child("Hello, World!")
    end if
    sync all
    if (this_image() /= 1) then
      coarray%item = coarray[1]%item
    end if
    select type (the_item => coarray%item)
    type is (child)
      print *, the_item%message
    end select
end program