J3/01-229

Date:    31st May 2001
To:      J3
From:    Malcolm Cohen
Subject: Pointer assignment is a mess


1. Introduction

The description of pointer assignment has suffered from various
well-intended
modifications which has ended up with it being very hard to read.  This
paper
attempts to simplify that section.

The basic approach is to separate out the BNF and associated constraints
for data pointers from that for procedure pointers.

Furthermore, there appear to be some errors, omissions and duplications in
this section.  I'll try to fix these too.

2. Dependencies

This paper depends on the "name infelicities" paper, in particular the
introduction of an explicit "<variable-name>".

This paper depends on the "pointer is a mess" paper, in particular the
definition of the term "data pointer".

3. Minimal edits to 01-007r1

If the full set of edits are not applied, we should at least do the
following
cleanup.

[32:41+] Insert note
"Note 4.4a
 Any entity with a deferred type parameter is required to have the
ALLOCATABLE
 or POINTER attribute."
{Move the second sentence of note 7.48, edited slightly, to the definition
of
 deferred type parameters.  We could delete it instead.}

[32:44+] Insert note
"Note 4.4b
 Deferred type parameters of functions, including function procedure
pointers,
 have no values.  Instead, they indicate that those type parameters of the
 function result will be determined by execution of the function, if it
returns
 an allocated allocatable result or an associated pointer result."
{Move the first sentence of note 7.48, edited slightly, to follow the
 description of what deferred type parameters means for objects.  We could
 just delete it instead.}

[137:20] Delete redundant and unnecessary text.
{Already covered by [108:10], which applies to all <pointer-object>s.}

[137:21] Delete redundant and unnecessary test.
{Already covered by [137:22-23] - scalars have rank zero and therefore no
 <bounds-spec>s are permitted.}

[137:37] Replace with
"Constraint: An <expr> shall be a reference to a function whose result is a
             pointer."
{Expressions don't have the "pointer attribute" (sic), and never did.  At
 least let us word it right for F2002.}

[137:38-41] De-constraintise and move to [138:2+].
{This is not determinable at compile time - just because <pointer-object>
has
 an explicit interface does not mean that <target> has an explicit
interface.}

[138:18-23] Delete the note.
{This note is confusing rather than explanatory.  For a start, the comment
 applies equally well to ordinary procedures as to procedure pointers.  For
 a second, one cannot even do type parameter enquiry on a procedure (again,
 whether a procedure pointer, dummy procedure, or normal procedure makes no
 difference).  For a third (and this is the killer), what is this stuff
about
 type parameters of procedures doing in the pointer assignment section?
Maybe
 it belongs in chapter 4, 5 or 12; it most certainly does not belong here.
 Some edits above insert corrected versions of this note into chapter 4.}

[138:25] After "disassociated" insert "or undefined".
{TECHNICAL CHANGE: The current text allows remapping undefined array
pointers.
 I think this is wrong.  Certainly the current text is broken, as it does
not
 make sense to put a size requirement on an undefined-association pointer.}

[138:29-30] Move "If ... -1." to the end of the paragraph.
{It makes no sense to say how to work out the upper bound before we've said
 how to work out the lower bound - the upper bound depends on the lower
bound.}

[138:35] Delete incorrect assertion "or ... (7.5.1.6)".
{This is not true - defined assignment does not "also" cause pointer
assignment
 to happen any more than any other subroutine reference.  It only happens if
 the subroutine executes a pointer assignment statement or a derived-type
 intrinsic assignment statement.}

4. Edits to 01-007r1

Comments to J3 embedded in edits are enclosed in {{}}, and are not intended
to
be inserted into the document.

[32:41+] Insert note
"Note 4.4a
 Any entity with a deferred type parameter is required to have the
ALLOCATABLE
 or POINTER attribute."
{Move the second sentence of note 7.48, edited slightly, to the definition
of
 deferred type parameters.  We could delete it instead.}

[32:44+] Insert note
"Note 4.4b
 Deferred type parameters of functions, including function procedure
pointers,
 have no values.  Instead, they indicate that those type parameters of the
 function result will be determined by execution of the function, if it
returns
 an allocated allocatable result or an associated pointer result."
{Move the first sentence of note 7.48, edited slightly, to follow the
 description of what deferred type parameters means for objects.  We could
 just delete it instead.}

[137:14+] Append to paragraph
"Any previous association between the pointer and a target is broken."
{If we are going to keep this useless redundant sentence, at least put it in
 the introductory waffle.}

[137:14+] Add new paragraphs
"Pointer assignment for a pointer component of a structure may also take
place
 by execution of a derived-type intrinsic assignment statement (7.5.1.5).

 A pointer may also become associated with a target by allocation of the
 pointer."
{If we are going to keep this useless drivel, at least put it in the
 introductory waffle.}

[137:15-138:37] Replace with:
"R735 <pointer-assignment-stmt> <<is>> <data-pointer-object> [ (
                                     <bounds-spec-list> ) ] => <data-target>
                                <<or>> <data-pointer-object> (
                                     <bounds-remapping-list> ) =>
<data-target>
                                <<or>> <proc-pointer-object> =>
                                     <proc-target>

 R735a <data-pointer-object> <<is>> <variable-name>
                             <<or>> <variable> %
<data-pointer-component-name>
 Constraint: A <variable-name> shall have the POINTER attribute.
 Constraint: A <data-pointer-component-name> shall be the name of a
component
             of <variable> that is a data pointer."

 R736 <bounds-spec> <<is>> <lower-bound> :

 R736a <bounds-remapping> <<is>> <lower-bound> : <upper-bound>

 R737 <data-target> <<is>> <variable>
                    <<or>> <expr>

 Constraint: A <data-pointer-object> shall be type-compatible (5.1.1.8) with
             <data-target>, and the corresponding kind type parameters shall
be
             equal.
 Constraint: A <variable> shall have either the TARGET or POINTER attribute,
             and shall not be an array section with a vector subscript.
 Constraint: An <expr> shall be a reference to a function whose result is a
             data pointer.
 Constraint: If <bounds-spec-list> is specified, the number of
<bounds-spec>s
             shall equal the rank of <data-pointer-object>.
 Constraint: If <bounds-remapping-list> is specified, the number of
             <bounds-remapping>s shall equal the rank of
<data-pointer-object>.
 Constraint: If <bounds-remapping-list> is specified, <data-target> shall
have
             rank one; otherwise, the ranks of <data-pointer-object> and
             <target> shall be the same.

 R737a <proc-pointer-object> <<is>> <proc-pointer-name>
                             <<or>> <variable> % <procedure-component-name>
 Constraint: A <procedure-component-name> shall be the name of a procedure
             pointer component of <variable>.

 R737b <proc-target> <<is>> <expr>
                     <<or>> <procedure-name>

 Constraint: An <expr> shall be a reference to a function whose result is a
             procedure pointer.
 Constraint: A <procedure-name> shall be the name of an external, module, or
             dummy procedure, a specific intrinsic function listed in 13.10
             and not marked with a bullet(.), or a procedure pointer.
 Constraint: The <proc-target> shall not be a nonintrinsic elemental
procedure.

 7.5.2.1 Data pointer assignment

 If the <target> is not a pointer, the <data-pointer-object> becomes pointer
 associated with the <target>.  Otherwise, the pointer association status of
 the <data-pointer-object> becomes that of the <target>; if <target> is
 associated with an object, <data-pointer-object> becomes associated with
the
 same object.

 If <data-pointer-object> is not polymorphic (5.1.1.8), <target> shall have
the
 same dynamic type as <data-pointer-object>.  Otherwise,
<data-pointer-object>
 assumes the dynamic type of <target>.

 If <target> is a disassociated pointer, all nondeferred type parameters of
the
 declared type of <data-pointer-object> that correspond to nondeferred type
 parameters of <target> shall have the same values as the corresponding type
 parameters of <target>.  Otherwise, all nondeferred type parameters of the
 declared type of <data-pointer-object> shall have the same values as the
 corresponding type parameters of <target>.

 If <pointer-object> has nondeferred type parameters that correspond to
 deferred type parameters of <target>, <target> shall not be a pointer with
 undefined association status.

 If <bounds-remapping-list> is specified, <target> shall not be a
disassociated
 or undefined pointer, and the size of <target> shall not be less than the
size
 of <data-pointer-object>.  The elements of the target of
 <data-pointer-object>, in array element order (6.2.2.2), are the first
 SIZE(<pointer-object>) elements of <target>.
{{TECHNICAL CHANGE: We ought not to allow remapping of undefined pointers.
  (See further comments in the "minimal edits" section).}}

 If no <bounds-remapping-list> is specified, the extent of a dimension of
 <data-pointer-object> is the extent of the corresponding dimension of
 <target>.  If <bounds-spec-list> is present, it specifies the lower bounds;
 otherwise, the lower bound of each dimension is the result of the intrinsic
 function LBOUND (13.11.58) applied to the corresponding dimension of
<target>.
 The upper bound of each dimension is one less than the sum of the lower
bound
 and the extent.

 7.5.2.2 Procedure pointer assignment

 If the <proc-target> is not a pointer, the <proc-pointer-object> becomes
 pointer associated with the <proc-target>.  Otherwise, the pointer
association
 status of the <proc-pointer-object> becomes that of the <proc-target>; if
 <proc-target> is associated with a procedure, <proc-pointer-object> becomes
 associated with the same procedure.

 If <proc-pointer-object> has an explicit interface, its characteristics
shall
 be the same as <proc-target> except that <proc-target> may be pure even if
 <proc-pointer-object> is not pure and <proc-target> may be an elemental
 intrinsic procedure even if <proc-target> is not elemental.

 If the characteristics of <proc-pointer-object> or <proc-target> are such
that
 an explicit interface is required, both <proc-pointer-object> and
 <proc-target> shall have an explicit interface.
{{TECHNICAL CHANGE: This requirement does not appear in 01-007r1.}}

 If <proc-pointer-object> has an implicit interface and is explicitly typed
or
 referenced as a function, <proc-target> shall be a function.  If
 <proc-pointer-object> has an implicit interface and is referenced as a
 subroutine, <proc-target> shall be a subroutine.
{{TECHNICAL CHANGE: This requirement does not appear in 01-007r1.}}

 If <proc-target> and <proc-pointer-object> are functions, they shall have
 the same type and type parameters.
{{COMMENT: This is for implicit interfaces, it is already covered for
explicit
ones.  It might also be a TECHNICAL CHANGE.}}

 If <procedure-name> is a specific procedure name that is also a generic
name,
 only the specific procedure is associated with <pointer-object>.
{{TECHNICAL CHANGE: This consequence is only spelled out for intrinsic
  procedures in 01-007r1.}}

 7.5.2.3 Examples
"

===END