(j3.2006) Comment concerning TEAM_TYPE
Tue Oct 8 20:13:57 EDT 2013
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
> ALLOCATE(b,SOURCE=a) ! TEAM_TYPE with POINTER attr?
>This violates C501, since b is a team variable.
(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
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
IF (IAND(THIS_IMAGE(),1)==0) THEN
TYPE(TEAM_TYPE),INTENT(IN) :: 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.
................................Malcolm Cohen, Nihon NAG, Tokyo.
More information about the J3