(j3.2006) Comment concerning TEAM_TYPE

[Malcolm Cohen]

On 10/7/13 11:56 PM, Malcolm Cohen wrote:
> While I thinking of strange things, this seems to be valid:
>    CLASS(*),POINTER :: a,b
>    TYPE(team_type),TARGET :: x
>     a => x
>    FORM TEAM(a,13)

That was supposed to be FORM TEAM(x,13) of course.  FORM TEAM should not permit 
its first argument to be CLASS(*) or TYPE(*), it needs to have the declared type 
being TEAM_TYPE.  (The dynamic type being an extension would not seem to be a 
problem.)

>     ALLOCATE(b,SOURCE=a) ! TEAM_TYPE with POINTER attr?

Bill replies:
>This violates C501, since b is a team variable.

Not so.

(a) In context, especially given its use in constraints, one might have thought 
that when you said
  "A scalar variable of type TEAM_TYPE is a team variable"
you were talking about the declared type.  In fact given its use in constraints 
you absolutely cannot be talking about the dynamic type!

(b) In any case, even if you change the words to mean dynamic type (and 
de-constraintify the requirements), B ***IS NOT*** a team variable until *AFTER* 
it has been allocated.  So there is no problem with it appearing in an allocate 
statement with source=.

>Lock and event variables have the same issue.  Maybe these
>cannot be constraints. ?

LOCK_TYPE might be a problem with the current standard.  Event and team are only 
in the TS so far, so we can decide how to fix those first, then go back and see 
if we want to do the same thing to locks.

>>     SELECT TYPE(b)
>>     TYPE IS (team_type)
>>        SYNC TEAM(b) ! b is a copy of a?
>
>Yes.  There is no ban on having two names for the same team.  You can write
>
>  form team (a, 13)
>  form team (b, 13)

Looks like two teams to me, whether they coincidentally have the same members or 
not.  Do we intend to allow synchronisation using different team variables that 
just happen to have the same images as members?  I find that a little 
surprising.

I also have a feeling that perhaps we might want to allow the implementation to 
update a team variable in the process of synchronisation.  That is, we should 
say that SYNC TEAM is a variable definition context.  I am thinking here of 
things like

   TYPE(TEAM_TYPE) a
   ...
   IF (IAND(THIS_IMAGE(),1)==0) THEN
     CALL sub(a)
   ELSE
     CALL sub((a))
  END IF
  ...
  SUBROUTINE sub(x)
    TYPE(TEAM_TYPE),INTENT(IN) :: x
    SYNC TEAM(x)

I was thinking that the implementation might want to write to the TEAM_TYPE 
object as part of the synchronisation process.  This would not be unreasonable. 
Of course it could have a pointer in the TEAM_TYPE pointing to some internal 
area that gets used, but that would be more complicated.

>>     DEALLOCATE(b) ! Deallocating TEAM_TYPE is ok?
>
>The omission of DEALLOCATE in the places where team variables can appear
>is corrected in Paper 13-336, first edit.

ok.

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