J3/00-296r1
Date:    20th September 2000
To:      J3
From:    Malcolm Cohen
Subject: Inconsistent association status

1. Introduction

There are a number of poorly specified association relationships.

(1) The relationship between the pointer association status of two pointers
    that are associated with each other (yes, I mean that the pointers are
    associated, not that their targets are associated [which is what ASSOCIATED
    tests]) is poorly specified in Fortran 95.  In particular, when two
    pointers are argument-associated the relationship is described in chapter
    12 via a copy-in copy-out model, but there is no text describing the
    relationship between two storage-associated pointers - e.g. pointers in
    COMMON.

    Now, if we get our "usual" restrictions right in the pointer case, this is
    equivalent to the "by-reference" model anyway.

    However, it cannot easily be used to describe the COMMON interactions.

    The model used to describe the relationship between the values of
    associated non-pointers is a "continuous" model (which for argument
    associated means by-reference), and is a model more suited to describing
    the effects of storage association.

(2) The model for host association of pointers is a continuous one, which is
    somewhat confusing since the standard apparently bypasses its normal
    fiction of the local host-associated and the host host-associated entities
    being separate but associated (with host association) and talks about
    manipulating the pointer to which the internal procedure "gains access"
    directly.  If this sort of language is acceptable for pointers, why for all
    these years have we been struggling with the association model for
    nonpointers?

(3) The semantics for allocatable variables that are associated by argument
    association are described in the standard by a copying model.
    (The usual restrictions prevent a user from telling the difference between
    this and the ordinary "continuous association" model).

    Strangely, the copying model specifies copy-in and appears to omit
    copy-out.  Perhaps some edit in the distant past lost this?  Oops.

    Anyway, there are no semantics for allocatable variables that are
    associated by other means, i.e. name association or pointer association.
    Such forms of association are best described by a continuous model rather
    than a copying model.

(4) The effects of allocation/deallocation/association on type parameters is
    described by a copying model, not a continuous model.  Again, this is
    erroneous, confusing and incomplete.

    5.1.2.7 already says that the type parameter values of a pointer with a
    pointer association status of "associated" are those of its target.  A
    disassociated/undefined pointer has no value for any deferred type
    parameter (it is forbidden to enquire about them - 6.1.3), so there is no
    need for any further specification of deferred type parameter values for
    pointers.

2. Examples

(3) Here is an allocation status example for allocatable variables that are
    associated by pointer association.

   MODULE m
     TYPE string
       CHARACTER(:),ALLOCATABLE :: value
     END TYPE
   END
   PROGRAM example
     USE m
     TYPE(string),TARGET :: x
     TYPE(string),POINTER :: y
     y => x
     ALLOCATE(CHARACTER(27)::x%value)
     ! y%value is now allocated with length 27
     DEALLOCATE(y%value)
     ! x%value is no longer allocated
   END

(4) Here is a parameterised derived type example for allocatable components
    with pointer association.

  MODULE m
    TYPE varchar(len)
      CHARACTER(len) :: value
    END TYPE
  END
  PROGRAM example
    TYPE person
      TYPE(varchar(:)),ALLOCATABLE :: name,address(:)
    END TYPE
    TYPE(person),TARGET :: x
    TYPE(person),POINTER :: y
    y => x
    ALLOCATE(TYPE(varchar(27)) :: x%name)
    PRINT *,y%name%len  ! prints 27
    DEALLOCATE(y%name)
    ALLOCATE(TYPE(varchar(42)):: y%name)
    PRINT *,x%name%len  ! prints 42
  END

3. Proposal

(1) Delete the copy-in/out model in chapter 12 and describe the effects of
    (argument/storage/etc.) association on pointer association status by a
    continuous model in chapter 14.

    There is no intended semantic difference between the text as it currently
    appears (where it provides semantics) and the new text; the only difference
    is to specify semantics for currently unspecified cases.

(2) Delete the erroneous description of host associated pointers.

(3) Delete the copy-in model in chapter 6 and describe the semantics of
    all associated allocatable variables by a continuous model (in chapter 6).

    (NB: Allocation status is covered in chapter 6, not in chapter 14).

(4) Describe type parameter effects together with allocation status, etc.

4. Edits to 00-007r2

[104:26-29] Replace paragraph
  "When the allocation status of an allocatable variable changes, the
   allocation status of any associated allocatable variable changes
   accordingly.  Allocation of an allocatable variable establishes values for
   the deferred type parameters of all associated allocatable variables."
{Change copy-in semantics to continuous semantics, and cover all forms of
 association, not just argument association.  Specify type parameter effects.}

[104:29+] Insert new paragraph
  "During execution, when an association is established to an allocatable
   entity, allocation status of the associating variable becomes that of the
   existing allocatable entity.  If the allocatable entity was currently
   allocated, the value of any deferred type parameter of the associating
   variable becomes the value of the corresponding type parameter of the
   existing allocatable entity.

   J3 internal note:
   This is intended to cover all forms of association (use/host/argument/...).
   It almost certainly needs more work - e.g. to explain the difference between
   the associating variable and the existing variable.  Also, we might wish to
   invent a new term to cover the allocation status together with the allocated
   entity with its bounds and type parameter values?  And the dynamic type?

   We might want to do something similar for pointers."
{Cover the creation of a new association for an existing allocatable variable.
 Note that once the association is established, the continuous model takes
 over so we don't need "copy-out".}

[256:29-32] Delete.
{Already covered by 5.1.1.8.}

[257:1-7] Delete.
{Remove copying model of deferred type parameters for argument association.}

[257:14-21] Delete.
{Remove copying model of pointer association status for argument association.
 Some of this is covered elsewhere already, some of it we'll cover in the
 usual way in chapter 14.}

[259:34-41] Delete.
{Some of this is covered already in 5.1.2.3; the rest will be covered by the
usual pointer rules in chapter 14.}

[350:4-9] Delete.
{This material is mostly erroneous, except for the remark about return from
 the procedure potentially making the host pointer undefined.  However, since
 this remark applies with equal force to use association, it is not suitable
 for discussion here.  In any case it is covered adequately by the normative
 text at 14.6.2.1.3 item 3.}

[352:26+] Insert new subclause
  "14.6.2.1.4 Other events that change the association status of pointers

   When a pointer becomes name associated, storage associated, or inheritance
   associated with another pointer, its association status becomes that of the
   other pointer.

   While two pointers are name associated, storage associated, or inheritance
   associated, if the association status of one pointer changes, the
   association status of the other pointer changes accordingly."
{Propagate pointer association status changes across other associations.}

{NOTE TO J3, NOT THE STANDARD: We already have, for nonpointers, the fiction
 that on exit from a procedure, argument associations are broken *before* the
 dummy variables disappear i.e. become "undefined".  This is implicit rather
 than explicitly stated (at least, I don't recall seeing it anyway).  We use
 the same fiction for pointers, and will for allocatables.}

===END