J3/03-227r1
Date: 18-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. However, an allocatable or pointer
polymorphic argument may have its type defined by an allocate
statement or by pointer assignment [76:11-12]. If that type is
defined in either the caller or callee, the corresponding argument in
the other program unit must have a compatible type. This is not
generally possible unless both the actual and dummy arguments are
polymorphic. A Note was suggested to clarify this section.
Edit:
[271:9+] Add Note 12.21+
"An allocatable or pointer polymorphic argument may have its type
defined by an allocate statement or by pointer assignment. If that
type is defined in either the caller or callee, the corresponding
argument in the other program unit must have a compatible type. This
is not generally possible unless both the actual and dummy arguments
are 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 avoid
this misinterpretation.
Edits:
[371:1] Replace "operators" by "operations"
[371:6-7] Replace "operators for" by "operations of"
[371:8-9] Replace by "whenever the operands or arguments are normalized
(if floating point) or are valid and within range (if another type),
and the IEEE result is normalized."
=======================================================================
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". The syntax for procedure declaration
is different from that for , so a better wording is
"specified in or inherited into". One, could, alternatively say that
"in" implies the inherited parts, and that text is OK as is. Edits to
make the change are supplied.
Edits:
[280:33] Replace "in" by "specified in or inherited into".
[280:36] Before "in" insert "specified".
[281:4] Replace "in" by "specified in or inherited into".
=========================================================================
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 and solve the problem. No additional edits are
required.
====================================================================