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

[Van Snyder]

On Mon, 2013-10-07 at 10:41 +0900, Malcolm Cohen wrote:
> An object of a type extended from LOCK_TYPE has a subobject of type
> LOCK_TYPE (the ancestor component)....

Malcolm is right, but there's more to it.

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, and then
not make it available for program-defined types because the standard
provides no syntax for it.

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,
since that's where the "say it twice and hope to get it right at least
once" effect is coming from.

The only difference between what we say for LOCK_TYPE, EVENT_TYPE and
TEAM_TYPE (with slight variation in the three cases), and the
attachment, is that the attachment prohibits mucking with the guts of a
protected type.  This is accomplished in the existing cases by making
all components private.

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

-------------- next part --------------
                                                             J3/13-xxx

To:        J3
From:      Van Snyder
Subject:   Protected types
Date:      2013 October 7
Reference: 97-114r2, 04-167, 13-214

Title: Protected types

Submitted by: Van Snyder

Status: For consideration

Basic functionality: Define a PROTECTED attribute for types.

Rationale:  The PROTECTED attribute is immanent in the description of
LOCK_TYPE in the current standard, and in the descriptions of EVENT_TYPE
and TEAM_TYPE in the draft coarray TS.  Describing it in one place would
simplify and unify description of those types, reducing the possibility
that they will be subtly different, and therefore potentially either
incomplete or wrong.  Since the facility necessarily exists, there is
very small justification for not allowing types defined by a program to
specify the attribute.

When this was pondered in 2004, the hate-dislike-like-love score was
0-0-11-0;

Estimated impact: Minor

Markham M6 conformance: Remove simple deficiency and discrepancy.

Detailed specification: Define a PROTECTED attribute for types.  If a
type has the PROTECTED attribute and the type definition is accessed by
use association:

      o a nonpointer dummy argument of the type, or that has a
        subcomponent of the type, shall not have INTENT(OUT),
      o a variable of the type, or that has a subcomponent of the type,
        shall not be in a common block,
      o a variable of the type, or that has a subcomponent of the type,
        shall not appear as
          - the <variable> of an <assignment-stmt>,
          - an <input-item> in a <read-stmt>,
          - a <variable-name> in a <namelist-stmt> if the
            <namelist-group-name> appears in a NML= specifier in a
            <read-stmt>, or
          - as the <allocate-object> in an <allocate-stmt> if the
            SOURCE= <alloc-opt> appears, and
      o a subcomponent of a variable of the type shall not appear in a
        variable definition context (16.6.7), a pointer association
        context (16.6.8), or as the <data-target> or <proc-target> in a
        <pointer-assignment-stmt>.

A type that has the PROTECTED attribute shall not be a SEQUENCE type.

If a type has the PROTECTED attribute, a pointer outside the module
where the type is defined vsn step through a linked list, but revising
pointers or component values within the list is prohibited.

Define LOCK_TYPE to be a protected type.  In the coarray TS, define
EVENT_TYPE and TEAM_TYPE to be protected types.

Draft edits: To estimate scope of project

Within a new subclause in 1.6 concerning Fortran 2008 compatibility,
insert

      o The PROTECTED attribute for a type restricts circumstances where
        a variable of the type may appear.

Insert an alternative for <type-attr-spec>

R427 <type-attr-spec> <<is>> ABSTRACT
                      ...
                      <<or>> PROTECTED

Within 5.3.15:

Insert a 5.3.15.1 <<General>> subclause, encompassing the introductory
blather of 5.3.15, C548 and C549.

Within C549, replace "procedure pointer or variable" by "procedure
pointer, variable, or derived type definition".

Insert a 5.3.15.2 <<PROTECTED attribute for variables and procedure
pointers>> subclause heading after C549.

After 5.3.15p3 insert a new subclause:

"
5.3.15.3 <<PROTECTED attribute for types>>

The PROTECTED attribute for a type imposes limitations on the usage of
variables of the type if the type is accessed by use association.

C552a If the definition of a type that has the PROTECTED attribute is
      accessed by use association

      o a nonpointer dummy argument of the type, or that has a
        subcomponent of the type, shall not have INTENT(OUT),
      o a variable of the type, or that has a subcomponent of the type,
        shall not be in a common block,
      o a variable of the type, or that has a subcomponent of the type,
        shall not appear as
          - the <variable> of an <assignment-stmt>,
          - an <input-item> in a <read-stmt>,
          - a <variable-name> in a <namelist-stmt> if the
            <namelist-group-name> appears in a NML= specifier in a
            <read-stmt>, or
          - as the <allocate-object> in an <allocate-stmt> if the
            SOURCE= <alloc-opt> appears, and
      o a subcomponent of a variable of the type shall not appear in a
        variable definition context (16.6.7), a pointer association
        context (16.6.8), or as the <data-target> or <proc-target> in a
        <pointer-assignment-stmt>.

C552b A type that has the PROTECTED attribute shall not be a SEQUENCE
      type.

NOTE 5.21a
  Unlike a variable with the PROTECTED attribute, a variable of a type
  with the PROTECTED attribute can be a <data-target> in a
  <pointer-assignment-stmt>.  This allows, for example, to traverse a
  linked list but prevents changing objects within the list.

NOTE 5.21b
  An object of a PROTECTED type can be initialized using the type
  constructor, provided all private components have default
  initialization.
"

In 13.8.2.16p1, in the first sentence, insert "protected (5.3.15.3)"
before "derived".

In 13.8.2.16, delete C1303 and C1304.

In 13-293 in 5.2p1, in the first sentence, replace "The derived type
TEAM_TYPE is an extensible" by "TEAM_TYPE is a protected (5.3.15.3)
derived".  {Since it's not specified to have the BIND or SEQUENCE
attributes, it's extensible.}

In 13-293, in 5.2, delete C501.

In 13-293, in 5.2, replace C502:

"C502 A variable with a subobject of type TEAM_TYPE shall not have the
POINTER attribute."

In 13-293 in 6.2p1, in the first sentence, insert "protected (5.3.15.3)"
before "derived".

In 13-293, in 6.2, delete C602 and C603.