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

[Van Snyder]

On Mon, 2014-06-02 at 12:06 +0900, Malcolm Cohen wrote:
> 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.

C643 and 6.7.1.1p4 both apply to the case of the <allocate-object> being
a coarray.  If it's unlimited polymorphic, it's not a coarray.

> 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...

We tried to constrain against changing the value of objects of type
LOCK_TYPE (and EVENT_TYPE) except by LOCK and UNLOCK (and EVENT POST and
EVENT WAIT) statements.

Allowing unlimited polymorphic objects opens the door to changes to
objects of type LOCK_TYPE that we didn't want to happen, such as copying
them, without an obvious syntactic clue that it's happening.

If we were to constrain against allocating unlimited polymorphic objects
and giving them type LOCK_TYPE, or a type with subobjects of type
LOCK_TYPE, that door would be closed.  Similarly for pointer assignment.
We don't need to worry about polymorphic other than unlimited
polymorphic because of 14-007r1:C438.

  type :: ONE
    type(lock_type), allocatable :: L[:] ! Conforms to C1302
  end type ONE

  type(one), target :: A, B
  class(*), pointer :: C, D
  class(*), allocatable :: E, F

  allocate ( a%l[*] )
  lock ( a%l )
  c => a
  d => b
  d = c ! Copies a lock, which C1303 cannot prevent
  b = a ! same effect as d=c, but prohibited by C1303
  allocate ( e, source=a ) ! Copies a lock, which C1303 cannot prevent
  allocate ( type(lock_type) :: f )
  select type ( f )
  type is ( one )
    allocate f%l[*] )
    lock ( f%l )
  end select
  f = e ! unlocks F, which C1303 cannot prevent

> > 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,