(j3.2006) Restrictions on LOCK_TYPE, EVENT_TYPE, and TEAM_TYPE

[Malcolm Cohen]

>Do we want to say (roughly) the same thing with three sets of (nearly)
>identical constraints, or do we want to do it once?  We remark in every
>meeting about the "say it twice, get it wrong at least once" rule.
>
>I suspect that implementations will develop something very much like a
>PROTECTED attribute for the special types from ISO_FORTRAN_ENV,

I see little connection between these special types and the purported PROTECTED 
attribute, which as far as I can see would not be of significant help in 
defining these special types.

If we had designed LOCK_TYPE et al differently, that is to say with the idea of 
making them PROTECTED types at the start and using that to advantage, there is a 
subset of their requirements that would (I think) be satisfied by said PROTECTED 
requirements.  But we did not.  Furthermore, each of these special types has a 
raft of requirements that have no connection with protectedness; some of these 
are unique to a single type, some of these are common to 2 or more of the types. 
We would still have to specify those.

Oh, and as for lack of duplication, in so far as it is possible it could be done 
anyway without any PROTECTED attribute e.g.

Cnnnn A variable of type LOCK_TYPE, EVENT_TYPE, or TEAM_TYPE, or which has a 
subobject of one of those types, shall not appear in a bad situation.

>I suspect that implementations will develop something very much like a
>PROTECTED attribute for the special types from ISO_FORTRAN_ENV,

I suspect not.

>I've revised the paper I sent by e-mail yesterday.  Maybe it ought to be
>considered as comments on the TS, rather than as a work item proposal,

The idea that extended coarrays, or even parallel programming in general, 
warrants adding a PROTECTED attribute to the language does not pass the 
credulity test.  Furthermore as demonstrated above, PROTECTED is unnecessary for 
avoidance of duplication and therefore needs to stand by itself.

>I am able to log in today, but the uploader says "malformed header" with
>no further explanation, so the revision is attached.

Perhaps the extra blank line between J3/13-nnn and To:?

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