J3/03-227r2

Date:    19-Aug-2003
To:      J3
From:    Toon Moene
Subject: Partial response to 03-201/N1524.

--------

Xrefs: 03-227/N1571 is the WG5 response to part of 03-201/N1524.

Page and line references are to 03-007.

=====================================================================
Part I (reply to comments in 03-201/N1524 on 03-173)

[271:7-9] currently states : "If a dummy argument is allocatable or a
pointer, the associated actual argument shall be polymorphic if and
only if the dummy argument is polymorphic, and the declared type of
the actual argument shall be the same as the declared type of the
dummy argument."

The original 03-173 responded to a Japanese comment that this
restriction was surprising.  A Note was recommended and is
supplied in the following edit.

Edit:

[271:9+] Add Note 12.21+

"The dynamic type of a polymorphic allocatable or pointer dummy
argument may change as a result of execution of an allocate statement
or pointer assignment in the subprogram. Because of this the
corresponding actual argument needs to be polymorphic and have a
declared type that is the same as the declared type of the dummy
argument or an extension of that type. However, type compatibility
requires that the declared type of the dummy argument be the same as,
or an extension of, the type of the actual argument. Therefore, the
dummy and actual arguments need to have the same declared type.

Dynamic type information is not maintained for a non-polymorphic
allocatable or pointer dummy argument.  However, allocating or pointer
assigning such a dummy argument would require maintenance of this
information if the corresponding actual argument is polymorphic.
Therefore, the corresponding actual argument needs to be
non-polymorphic."


=================================================================
Part II (reply to comments in 03-201/N1524 on 03-180)

The first sentence of 12.4.3, [278:10-11], which discusses subroutine
invocation, mentions "finalization", but the sentence in [278:13-14],
which discusses subroutine completion, does not. Finalization is
sufficiently different from the other mechanisms listed in [278:13-14]
that it should not be included in that list.

The structure of the list in [278:14] makes the meaning unclear, and
the use of articles in the list is inconsistent.  Clarifying edits are
supplied.

Edits:

[278:13] Insert "the" before "execution".

[278:14] Insert "the execution of the" before "defined".


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

Part III (reply to comments in 03-201/N1524 on 03-183)

The sentence structure in [371:6-9] in 03-007 is ambiguous and the use
of the term "operators for" is confusing.  Edits are supplied to fix
this.  The final part of the sentence, "or valid and within range (if
another type)" refers to operands or arguments that are not floating
point.  The current structure could be read to allow the IEEE result
to be a non-floating point. An edit rearranges the sentence to read:

"For each of the operations of addition, subtraction, and
multiplication, the result shall be as specified in the IEEE standard
whenever the IEEE result is normalized and the operands are normalized
(if floating point) or are valid and within range (if another type)."

Also note that the wording in [371:3] is not consistent with the IEEE
standard, in which "rem" is an operation and not a function. Edits
provided to fix this.

Edits:

[371:1]   Replace "operators" by  "operations"
[371:3-5] Replace "and the functions ... IEEE_UNORDERED." by

"the IEEE operation rem shall be provided by the function IEEE_REM;
and the IEEE functions copysign, scalb, logb, nextafter, and unordered
shall be provided by the functions IEEE_COPY_SIGN, IEEE_SCALB,
IEEE_LOGB, IEEE_NEXT_AFTER, and IEEE_UNORDERED, respectively."

[371:6-7] Replace "operators for" by "operations of"
[371:8-9] Replace by "whenever the IEEE result is normalized and the
          operands are normalized (if floating point) or are valid
          and within range (if another type).


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

Part IV (reply to comments in 03-201/N1524 on 03-186)

The current text in section 2.4.6 [18:22-31] does not discuss the
pointer association status of undefined. This is parallel to section
2.4.3.1.1 which does not discuss undefined variables. It is sufficient
to leave the discussion of undefined status to section 16.4.2.1.3, so
no edits are proposed for section 2.4.6.

The sections 4.5.3.1 and 4.5.3.2 are short, but this does not seem to
be a problem.  However, three of the Notes in these sections begin
with effective restatements of the normative text just above.  This is
unnecessary. The notes are just examples and the text should read that
way.  Edits are supplied to fix the Notes.

Edits:

[50:15+2] Replace first line of Note 4.29 by "An example of a derived
type with an array component is:"

[50:15+20] Replace first line of Note 4.30 by "An example of a derived
type with an allocatable component is:"

[51:3+2] Replace first line of Note 4.32 with "An example of a derived
type with a pointer component is:"


=======================================================================
 Part V (reply to comments in 03-201/N1524 on 03-188r1)

Section 12.4.5 contains 3 references to "binding with that name in the
... type".  Papers 03-101 and 03-188r1 propose to change "in" to
"declared in or inherited into". This is not considered to be an
improvement. However, the sentence in [280:32-34] and [281:3-4] could
be simplified.

Edits:

[280:33] Replace "identified by the binding with" by "bound to"

[281:3] Relace "identified by the binding with" by "bound to"

[281:4] Delete ",".

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

Part VI (reply to Miscellany at the end of  03-201/N1524)

Two lines [220:27,29] extend over into the margin by two
characters. Paper 03-212, in the section referring to N1543 (which is
03-205), recommends that one layer of section headings in 13.8.2.x.x
be removed. This will reduce the length of lines [220:27,29] by 2
characters each. Edits to shorten the lines more:

[220:23] after "defined" add "with"

[220:24] replace "With a" by "A"

[220:26] replace "With a" by "A"

[220:27] replace "With the" by "The"

[220:29] replace "With the" by "The"
====================================================================