(j3.2006) Unlimited polymorphic and LOCK_TYPE (and EVENT_TYPE)

[Malcolm Cohen]

On May 30, 2014, at 7:01 PM, Van Snyder <Van.Snyder at jpl.nasa.gov> wrote:
> There needs to be a constraint against the <source-expr> being of type
> LOCK_TYPE (or EVENT_TYPE in the TS) if any <allocate-object> is
> unlimited polymorphic.

I do not see why you think that.

Bill Long replied:
>If the <source-expr> is type  X  does that not make the <allocate-object> also 
>type X, and no longer unlimited polymorphic?

The declared type of <allocate-object> is not affected by <source-expr>.

>Seems like an issue needing an opinion from /DATA.

Apparently not.

>    Not that the suggested constraint would be wrong - just whether it is 
> necessary.  And whether we are setting ourselves up for similar patches in the 
> future.

Looking at 14-007r1, the allocation of things regarding LOCK_TYPE is governed by 
two requirements: C643 which covers the declared type of <source-expr> when 
<allocate-object> is a coarray, and subsequently p4 which covers the dynamic 
type of <source-expr> when <allocate-object> is a coarray.

Obviously we were happen with the runtime requirement on the dynamic type when 
we wrote 6.7.1.1p4.

> For LOCK_TYPE, this needs an interp.

Um, where is this concern about unlimited poly coming from?  If it's just a few 
lines of code, the code would have been a handy guide as to what we're talking 
about...

> There needs to be a constraint against the <data-target> being of type
> LOCK_TYPE (or EVENT_TYPE in the TS) if the <data-pointer-object> is
> unlimited polymorphic.

Ok, so a lock variable has to be a coarray, and except in the case of unlimited 
poly this has to be visible in the declared type (14-007r1 C438).  So perhaps 
the example we're supposed to be talking about is

  TYPE door
    TYPE(LOCK_TYPE) :: lock
  END TYPE
  TYPE(door),TARGET :: front[*]
  CLASS(*),POINTER :: p,q,r
1 p => front
2 ALLOCATE(q,SOURCE=front)
3 ALLOCATE(r,SOURCE=p)
4  CALL inner(front)
   ...
CONTAINS
   SUBROUTINE inner(s)
     CLASS(*) s

Ok, so statement 1 gives us a (non-coarray) pointer with a dynamic type 
containing a lock variable (front%lock).  And statement 2 gives us a non-coarray 
copy of a lock variable, and statement 3 ditto.  Statement 4 gives us an 
argument-associated one.

Ok, so once we have our CLASS(*) pointer to or copy of a lock variable, then we 
can do something like

  SELECT TYPE(p) ! or q or r
  TYPE IS (door)
    LOCK(p%lock)

Is this valid?  Obviously for Q or R no interpretation (semantics) is 
established, so they are definitely caught by the catchall (unsatisfactory 
though that would be).

There is no requirement I see in the LOCK statement for the lock-variable to be 
a coarray.  However, the construct entity P within the TYPE IS (door) block has 
a declared type with a noncoarray component of type LOCK_TYPE, but P is not a 
coarray itself, so that clearly violates C1302.

Therefore this is in fact invalid (without resorting to the catchall).

Actually one might also argue that all of statements 1-4 violate C1302 already, 
in that they are known at compile time to establish an entity to have a dynamic 
type of type LOCK_TYPE without being a coarray.

So I am not yet convinced there is a problem here that needs to be solved, 
though there might be wording issues that could be improved.  But perhaps Van 
has some different example(s) in mind?

Cheers,
-- 
................................Malcolm Cohen, Nihon NAG, Tokyo.