[J3] US-12 apparently incomplete

[John Reid]

Malcolm Cohen via J3 wrote:
>
> Sorry, I do not see the problem here with type-spec or MOLD=. All 
> allocatable components spring into existence unallocated. No 
> communication between images is necessary!
>

Oh dear! I overlooked the intention that for an object with a coarray 
ultimate component DEALLOCATE is an image control statement, but 
ALLOCATE is not.
>
> Even in F2008, we have
>
>   TYPE t
>
>     REAL,ALLOCATABLE :: c[:]
>
>   END TYPE
>
>   ...
>
>   RECURSIVE SUBROUTINE rs
>
>      TYPE(t) w ! Not a coarray, subroutine entry has no sync implied 
> or needed
>
>      ! The c component springs into existence unallocated, on each 
> execution of rs.
>
> And US-12 lets us have ALLOCATABLE thingos with coarray components, thus
>
>   TYPE(t),ALLOCATABLE :: x
>
>   ALLOCATE(x) ! Not a coarray, no sync implied or needed.
>
> This is allowed, and is part of the US-12 requirements so we’re not 
> about to delete it (unless we delete a significant part of US-12 
> functionality). And if that is okay, there is certainly nothing wrong with
>
>   CLASS(*),ALLOCATABLE :: y
>
>   ALLOCATE(t::y) ! Not a coarray, no sync implied or needed.
>
> Now I do agree there are issues with coarray components:
>
>  1. SOURCE= as there would be a copying (allocation) of the coarray
>     components
>  2. DEALLOCATE if the object is CLASS(*)
>  3. Intrinsic assignment if the object is CLASS(*)
>
> To treat these one-by-one:
>
>  1. I think(*) that the user should have to manage the coarray
>     allocations himself, which means
>
> i)the declared type of the SOURCE= expr should not be allowed to have 
> coarray components [CONSTRAINT],
>
> ii)for CLASS(*) only, the dynamic type ditto [RUNTIME REQUIREMENT];
>
>  2. the dynamic type should not be allowed to have coarray components;
>  3. the dynamic type should not be allowed to have coarray components.
>
I am fine with this and will prepare a paper for review by HPC and 
yourself.

Cheers,

John.




> I see no grounds for relaxing the ALLOCATE/DEALLOCATE requirements if 
> some other completely-unrelated object in the statement is a coarray. 
> That would be extremely strange language design.
>
> (*) ASIDE: It is arguable that having the compiler manage subcomponent 
> coarray allocations would be fine, but my opinion is that this would 
> be too big a burden, and leads to inconsistencies with CLASS(*).
>
> Cheers,
>
> -- 
>
> ..............Malcolm Cohen, NAG Oxford/Tokyo.
>
> *From:* J3 <j3-bounces at mailman.j3-fortran.org> *On Behalf Of *John 
> Reid via J3
> *Sent:* Sunday, August 22, 2021 8:07 PM
> *To:* Malcolm Cohen via J3 <j3 at mailman.j3-fortran.org>
> *Cc:* John Reid <John.Reid at stfc.ac.uk>
> *Subject:* Re: [J3] US-12 apparently incomplete
>
> Dear all,
>
> Sorry to be slow to reply to this.
>
> I have come to the conclusion that a problem occurs if an
> <allocate-object> is unlimited polymorphic and is given a dynamic type
> with a coarray ultimate component by <type-spec> or <source-expr>. This
> could mean that whether the ALLOCATE statement is an image control
> statement is dynamic. The same goes for the DEALLOCATE statement for the
> object. We need to disallow this. We could effect this by keeping
>
> C953 (R932) The declared type of <source-expr> shall not have a coarray
> ultimate component.
>
> and adding a similar constraint on <type-spec>, but this is too big a
> club because an <allocate-object> might be a polymorphic variable with a
> declared type that has a coarray ultimate component, or there might be
> other <allocate-object>s that make the statement an image control
> statement.
>
> I suggest deleting C953 and adding this text
> "If no <allocate-object> is a coarray or has a type with a coarray
> ultimate component and an <allocate-object> is unlimited polymorphic,
> the dynamic type of neither <type-spec> nor <source-expr> shall have a
> coarray ultimate component."
>
> While working on this, I have found what I think are minor problems with
> the way ALLOCATE and DEALLOCATE  are described when they are image
> control statements. I will work with HPC to prepare a paper for the
> October meeting.
>
> Cheers,
>
> John.
>
> John Reid wrote:
> > Malcolm,
> >
> > I will try to get an answer to you tomorrow, but I will not have much
> > time and it is not an area that I find at all easy.
> >
> > Sorry not to be quicker.
> >
> > John.
> >
> >
> > Malcolm Cohen via J3 wrote:
> >>
> >> Hi folks,
> >>
> >> Paper 19-250r1 added allocatable entities containing coarray
> >> components, and thus deleted the constraint (on ALLOCATE) that
> >> type-spec shall not have an ultimate allocatable component.
> >>
> >> However, the constraint further down remains:
> >>
> >> C953 (R932) The declared type of /source-expr /shall not have a
> >> coarray ultimate component.
> >>
> >> Presumably (?) this should be part of C952, and thus apply only to
> >> SOURCE= (where it would be problematic) and not to MOLD= (where it is
> >> not problematic).
> >>
> >> Cheers,
> >>
> >> --
> >>
> >> ..............Malcolm Cohen, NAG Oxford/Tokyo.
> >>
> >
>
> *Disclaimer*
>
> The Numerical Algorithms Group Ltd is a company registered in England 
> and Wales with company number 1249803. The registered office is: 30 
> St. Giles, Oxford, OX1 3LE, United Kingdom. Please see our Privacy 
> Notice <https://www.nag.co.uk/content/privacy-notice> for information 
> on how we process personal data and for details of how to stop or 
> limit communications from us.
>
> This e-mail has been scanned for all viruses and malware, and may have 
> been automatically archived by Mimecast Ltd, an innovator in Software 
> as a Service (SaaS) for business.
>