(j3.2006) Comment concerning TEAM_TYPE
Van Snyder
Van.Snyder
Tue Oct 8 15:02:11 EDT 2013
On Tue, 2013-10-08 at 13:56 +0900, Malcolm Cohen wrote:
> One might also wonder about the utility of such things as
> Type(team_type) x
> Call s(Transfer(123,x))
> I mean, this is bad enough with LOCK_TYPE but with TEAM_TYPE the
> results should
> be hilarious. Some additional requirements along the lines of "the
> result of a
> function reference shall not be of type TEAM_TYPE" might be worth
> considering.
>
> 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)
> ALLOCATE(b,SOURCE=a) ! TEAM_TYPE with POINTER attr?
> SELECT TYPE(b)
> TYPE IS (team_type)
> SYNC TEAM(b) ! b is a copy of a?
> END SELECT
> DEALLOCATE(b) ! Deallocating TEAM_TYPE is ok?
>
> ...perhaps we ought to consider forbidding TARGET with TEAM_TYPE too,
> otherwise
> half of the constraints are pretty pointless. Or adding runtime
> requirements.
Maybe objects of type team_type (and event_type and lock_type) ought to
be prohibited as arguments, or at least as the MOLD argument, to
Transfer.
One might also wonder about the utility of named constants of team_type.
Sure, you can't create them without the constructor, but that's a
different issue.
Do we want to allow variables of lock_type, team_type or event_type in
common? There is an indirect prohibition for variables of event_type
and_lock_type because they have to be coarrays, but subclause 5.2 of the
TS doesn't prohibit it for team_type indirectly because team_type is
prohibited to be a coarray, and the TS doesn't say team_type doesn't
have the SEQUENCE (or BIND) attribute.
I think it's a pipe dream that the coarray TS will be ready for
publication after 202. There are too many brand-new ideas, especially
concerning teams, that haven't been tested, or thought through far
enough.
More information about the J3
mailing list