J3/01-385

Date:     November 29, 2001
To:       J3
From:     Dick Hendrickson
Subject:  Technical issues in Chapter 8

1)  Page 152[15] C808.  Why do we need this constraint?  None of the other
syntax for SELECT TYPE depends on having an associating name.  Granted, it's
useful thing in many cases; but why should it be required?

PROPOSAL  Change C808 to
"NOTE nnn
Usually if the selector is not a simple name an associate-name will be used.
Otherwise there is no easy way to refer to the selector within one of the
type-guard-statement blocks."

If we do this we need to check the wording to effectively add "if any" in a
few of the descriptions of the associate-name.

2)  Page 152[17] C810.  Do we need this constraint?  It seems to me it
prevents stubbing out SELECT TYPE constructs during code development.  We
allow things like

      INTEGER, PARAMETER  :: I = 7
      SELECT CASE (I)
          ...

Isn't a SELECT TYPE with a non-poly-morphic selector the same sort of thing?

PROPOSAL  Page 152[17]  Delete C810

3)  Page 153[25]  section 16.7.1.5 describes association between two things
and says the association is broken at the end of the block.  But here lines
9 and 10 say that in the degenerate case the name itself is the associate
name.  It sounds odd to me to say that a thing gets associated with itself
and later on disassociated from itself.  I think we need to clarify 16.7.1.5
for the degenerate case.

4)  154[20]  Selectors don't have a "declared type" if they are expressions
(or maybe even if they are implicitly typed).  Same problem with C811, page
153, and other uses of "declared type of the selector"

PROPOSAL  153[ 4] delete "declared"
          154[ 2] delete "declared"
          154[ 3] delete "declared"
          154[ note 8.12] delete "declared"
          154[20] delete "declared"

5)  154, C815.  C815 would appear to allow assigning to an associated name
that is associated with a protected variable.  That coupled with 8.1.4.5
seems to imply that the associated name is not protected.

6)  Page 154[27].  Should other attributes also leak in?  How about
OPTIONAL, PARAMETER, PROTECTED, and VALUE?

7)  Page 154, 8.1.4.5  I'd read 16.7.1.5 as to say that a line like
ASSOCIATE ( name => george) doesn't reference george.  So, is george allowed
to be OPTIONAL?

8)  Page 154[27].  What does "same rank and bounds" mean?  Does it mean as
if LBOUND and UBOUND were applied to selector?  Other places (e.g. 137[7] )
explicitly talk about LBOUND and extent.  Yet natural English implies that
ASSOCIATE (A => array(3:7) )
will give A with bounds 3 and 7.  This seems to also be the natural
shorthand intent of ASSOCIATE.

I think the intent is that the association be dummy argument like with
bounds 1:extent, but we should say that.  We could also do something like we
did for POINTER and allow
associate-name[(bounds-list)] => selector
with suitable constraints on bounds-list to preserve the "natural"
subscripts.  Or perhaps
associate-name[(:,:,:,:)] => selector
to mean that the associate gets the actual bounds, not 1:extent.

I'm not sure what the committee's intent was here.

9)  Page 382, lines 5 to 13.  I think there is a problem with limiting the
scope of the associate name to the BLOCK of the construct.  This leave out
the header line.  I think there was a similar interp about FORALL (I = I,
I+1), but I don't remember the details.  Given something like
       name = 0
       associate (name => name + 1)
           print *, name
       end associate
It's clear that the use of name in the print refers to the associate name.
But, what about in the associate line itself?  And what about   associate
(name => name+1, other_name => name+2)