J3/03-158R1
                                                     Page 1 of 1

Date:      31 March 2003
Subject:   Some more loose ends
From:      Van Snyder
Reference: 02-284r2


While investigating Richard Maine's concerns about the description of one
aspect of host association on page 402, I decided to compare that
description to the description of the parallel problem and its solution
with respect to use association.  Even though the situation with respect
to use association is much more clearly described, it is still rather
rough.  This paper attempts to tie up a few loose ends in this area.  It
is an attempt to finish the work begun in 02-284r, which is incorporated
into the US position laid out in 03-107r1.

[248:28-36]  It's not a USE statement, but use association, that gives
access to entities.  Editor: ``a USE statement'' => ``use association'' at
[248:28]; ``USE statements'' => ``use association'' at [248:29]; ``a USE
statement'' => ``use association'' at [248:30]; ``contains the USE
statement'' => ``accesses the entity by use association'' at [248:32];
``the USE statement'' => ``use association'' at [248:36].

[248:31-34] An entity declared using a type declaration statement and then
accessed as a function in an executable statement in the same scoping unit
as the type declaration thereby acquires the external attribute.  We don't
want this to happen if an entity declared only by a type declaration
statement is accessed by use association and then referenced as a
function.  One can deduce this by proving a theorem involving [249:1-5]
but it's easierto observe if we don't exclude executable statements here.
Editor: Delete ``nonexecutable'' at [248:31]; replace ``and'' by a comma
at [248:33]; insert ``, or a deferred type parameter may become defined or
undefined'' after ``attribute'' at [248:34].

[248:31] There are more attributes, and ways to specify them, than laid
out in 5.1.2.  In particular, the general definition of the term
``attribute'' is at [67:2-3].  Editor: Insert a cross reference to
Section 5 before the reference to 5.1.2 at [248:31].

===========================================================================

On 19 and 20 March, a few more loose ends came to light.

[105:28] Editor: Insert "or ALLOCATABLE" after "POINTER".

[143:12-13] Notice that R517 and R518 define <lower-bound> and
<upper-bound> to be <specification-expr>s.  We shouldn't restrict the
bounds in an executable statement to be specification expressions.  Also,
we don't want even a hint of C550 here.  Editor: Replace by

"R737  <bounds-spec>          <<is>> <lower-bound-expr> :
 R738  <bounds-remapping>     <<is>> <lower-bound-expr> : <upper-bound-expr>
 R738a <lower-bound-expr>     <<is>> <scalar-int-expr>
 R738b <upper-bound-expr>     <<is>> <scalar-int-expr>"

Note to Editor: <scalar-int-expr> is \st{scalar-}\si{int-expr}.

[143:13] Do we want to *require* that the lower bounds be specified
explicitly?  It seems that we could have

 R738  <bounds-remapping>     <<is>> [ [ <lower-bound-expr> ] : ] \smudge
                                     \smudge <upper-bound-expr>

or at least

 R738  <bounds-remapping>     <<is>> [ <lower-bound-expr> ] : \smudge
                                     \smudge <upper-bound-expr>

STRAW VOTE: 1. Continue to require lower bounds in <bounds-remapping>?
            2. Allow the <lower-bound-expr> to be omitted but not the colon?
            3. Allow the <lower-bound-expr> and colon to be omitted?

[143:32] If <bounds-remapping-list> is specified, the <data-pointer-object>
need not become associated with all of the <data-target>.  Editor: Insert
"all or part of" after "with".

[144:1] "<pointer-object>" isn't germane here.  Editor: Replace it with
"<data-pointer-object>".

[144:3-6] doesn't specify the size, and makes a requirement that the
<data-target> is not a disassociated or undefined pointer, which is
inconsistent with [104:30-31]  Also, the <pointer-object> at [144:5]
isn't germane here; it ought to be <data-pointer-object>.  Editor:
Replace the paragraph with an unnumbered list:

"If <bounds-remapping-list> is specified and <data-target> is associated
with a target:
  o The shape and size of <data-pointer-object> are determined by the
    values of the <lower-bound-expr>s and <upper-bound-expr>s in the same
    way as the shape and size of an explicit-shape array are determined
    by the values of its <lower-bound>s and <upper-bound>s (5.1.2.5.1),

[Note to J3 -- not part of the edit: By saying "values of" we restrict
reference to the last paragraph of 5.1.2.5.1, so that we don't get stuff
about automatic arrays sucked into this discussion.  The discussion in
the last paragraph of 5.1.2.5.1 covers the case of an omitted
<lower-bound> so we don't need anything special here if the outcome of
the straw vote above regarding R738 is not option 1.]

  o The size of <data-target> shall not be less than the size of
    <data-pointer-object>, and
  o The elements of <data-pointer-object>, in array element order (6.2.2.2),
    are the first SIZE(<data-pointer-object>) elements of <data-target>."

There's an edit in 03-107r1 that italicizes "bounds-remapping-list" at
[144:3].  That edit becomes irrelevant if this one passes.

[144:7] Editor: Replace "present" with "specified".

[151:10-15] "<pointer-object>" isn't germane here.  Editor: Replace it
with "<data-pointer-object>" four times.