Non-identified corrections
UTIs
Subgroup recommeds deleting 3.120 same instance from glossary.
Correct definition would be complex and just repeat normative text.
Subroup agrees. We will add a fake term with cross-reference.
Subgroup mildly disagrees with the suggested fix options. Needs
further discussion with the editor.
Subgroup agrees that the wording is incorrect. Probably dromp "the
value of". (May also need to purge "implied-rank" or "deferred-rank"
and similar.)
Example needs to be examined/fixed
The editor appears to be inconsistent. Here "template" implies both
template construct and templated procedure. (As the editor has
asserted in other locations.)
Inclined to just add explicit for both here to avoid.
Subgroup agrees. We will delete the note.
Subgroup agrees. We will put a simple example here and leave a more
complex example to later when more terminology has been introduced.
Subgroup agrees. Must verify that C1616 is indeed duplicated in the
"correct" place.
Subgroup is concerned that there may not be sufficient time to work
through this.
Delete last sentence of the note. Unless UTI012 results in permitting
coarrays.
Subgroup agrees - will delete "or templated subprogram".
(Why a UTI instead of just an editor fix?)
Subgroup agrees. constraints already deleted in 26-007r1.
TBD - subgroup needs to better understand whether "previously defined"
means what we think it means and if it is sufficient.
more of the same with UTI018 probably agree
TBD
more of the same with UTI018 probably agree
agreed. Note 2 can be deleted.
subgroup agrees - will move this section down to later in the doc
TBD - try to improve wording of p2 on page 409. Subgroup thinks we
pretty much copied the text from procedure arguments. If the editor
can improve 15.5.2.1, we can follow suit.
The issue is that the procedure must be known at time of
instantiation.
Subgroup intent: disallow procedure pointers but not a catastrophe to
allow. Will look for motivating and/or interesting use cases.
(Procedure pointer component pointing to instantiation procedure?)
If pointer is default initialized, are you pointing at the initial state?
- No such thing as an "intrinsic" generic identifier
- Paragraphs below must be rewritten:
If a deferred procedure corresponds to a nonintrinsic generic
identifier, it becomes associated with the specific procedure that is
a member of that generic identifier that has the same characteristics
except whether it is PURE, SIMPLE, or ELEMENTAL.
If a deferred procedure corresponds to an intrinsic generic
identifier, it becomes associated with that intrinsic identifier.
Hopefully just a matter of removing "nonintrinsic" from Ctt58.
We accept editor's change here.
Subgroup disagrees. It does not require analysis of the entire
template - only that the procedure in question can be used in the same
way that a procedure with the specified interface could be used.
Subgroup agrees that the existing wording is inadequate.
Subgroup accepts the change. Does not really seem like a UTI.
We agree with the editor's change.
From editors report
"COMMENT (in remaining note i.e. example) actually, I think the template and
templated subprogram should be right here! Put a simpler example
where they are now." (16.3 and 16.5)
COMMENT I do not understand why this restriction is desirable.
(A \si{requirement-construct} shall only appear in the
\si{specification-part} of a main program or module.)
{We were worried that you could end up with something circular if we
relax this. We are confident that you can always move these to module
spec section.}
DIFF (Examples of REQUIREMENT and REQUIRE) I changed the names of the deferred
arguments of R2 to make it less confusing to read.
We will meet you half way. We want the arguments to be {T, F} instead
of {type, func}.
Probably not worth pursuing, but caught our eye:
Non-identified corrections
UTIs
Subgroup recommeds deleting 3.120 same instance from glossary.
Correct definition would be complex and just repeat normative text.
Subroup agrees. We will add a fake term with cross-reference.
Subgroup mildly disagrees with the suggested fix options. Needs
further discussion with the editor.
Subgroup agrees that the wording is incorrect. Probably dromp "the
value of". (May also need to purge "implied-rank" or "deferred-rank"
and similar.)
Example needs to be examined/fixed
The editor appears to be inconsistent. Here "template" implies both
template construct and templated procedure. (As the editor has
asserted in other locations.)
Inclined to just add explicit for both here to avoid.
Subgroup agrees. We will delete the note.
Subgroup agrees. We will put a simple example here and leave a more
complex example to later when more terminology has been introduced.
Subgroup agrees. Must verify that C1616 is indeed duplicated in the
"correct" place.
Subgroup is concerned that there may not be sufficient time to work
through this.
Delete last sentence of the note. Unless UTI012 results in permitting
coarrays.
Subgroup agrees - will delete "or templated subprogram".
(Why a UTI instead of just an editor fix?)
Subgroup agrees. constraints already deleted in 26-007r1.
TBD - subgroup needs to better understand whether "previously defined"
means what we think it means and if it is sufficient.
more of the same with UTI018 probably agree
TBD
more of the same with UTI018 probably agree
agreed. Note 2 can be deleted.
subgroup agrees - will move this section down to later in the doc
TBD - try to improve wording of p2 on page 409. Subgroup thinks we
pretty much copied the text from procedure arguments. If the editor
can improve 15.5.2.1, we can follow suit.
The issue is that the procedure must be known at time of
instantiation.
Subgroup intent: disallow procedure pointers but not a catastrophe to
allow. Will look for motivating and/or interesting use cases.
(Procedure pointer component pointing to instantiation procedure?)
If pointer is default initialized, are you pointing at the initial state?
Hopefully just a matter of removing "nonintrinsic" from Ctt58.
We accept editor's change here.
Subgroup disagrees. It does not require analysis of the entire
template - only that the procedure in question can be used in the same
way that a procedure with the specified interface could be used.
Subgroup agrees that the existing wording is inadequate.
Subgroup accepts the change. Does not really seem like a UTI.
We agree with the editor's change.
From editors report
verify that "templated procedure" --> "templated subprogram" throughout.
maybe remove glossary term "instantiation association"
verify that "templated-subroutine-subprogram" -->
"templated-subr-subprogram"; same for "function" --> "func"
If you delete glossary term "ultimately defined prior" there is no
definition for either of the 2 places it is used. And "defined
prior" is not sufficient.
5.3.2 Statement order - we feel that TEMPLATE should be included.
Yes, it is not a program unit, but ... the table does not say that
it is.
If you reject the edit below, then what is a deferred type in the
typing system? Subrgroup believes this is a new kind of type.
REJECT This is not a new kind of type.
[51:27+] After 5.4.1.3 Derived type, add a new subclause:
We are concerned that this rejection has unintended consequences.
REJECT absolutely no need
[118:19] Modify R818 to disambiguate lower and upper explicit bounds
We think the edits for 8.5.8.8 Implied-rank entity missed something in the 3rd bullet.
can also depend on the SHAPE of a deferred constant.
Also cannot have DEFERRED REAL constant - fix example
Rename 8.5.8.8 "Deffered" rank, and adjust text accordingly.
Edits to 8.8 made a technical change:
"the default for a TEMPLATE construct, templated subprogram, or an
interface body contained therein, is the null mapping."
Subgroup intended to allow ordinary interfaces to keep old rules;
new deferred interfaces have special rules.
May muddy the water. Need thought/discussion.
15.5.1 We think we still need to mention inline instantiation for R1522
15.5.1 We think we still need to mention for R1522
15.5.1 and we need in R1524
16.5.2 Maybe we should disallow recursive templated subprograms. (see note 1)
16.5.5.4 Instantiation association of a deferred procedure p412 p1
"is treated as a procedure"? We disagree and/or do not
understand. You cannot assume is a procedure everywhere else. (E.g., operators.)
"COMMENT (in remaining note i.e. example) actually, I think the template and
templated subprogram should be right here! Put a simpler example
where they are now." (16.3 and 16.5)
COMMENT I do not understand why this restriction is desirable.
(A \si{requirement-construct} shall only appear in the
\si{specification-part} of a main program or module.)
{We were worried that you could end up with something circular if we
relax this. We are confident that you can always move these to module
spec section.}
DIFF (Examples of REQUIREMENT and REQUIRE) I changed the names of the deferred
arguments of R2 to make it less confusing to read.
We will meet you half way. We want the arguments to be {T, F} instead
of {type, func}.
Probably not worth pursuing, but caught our eye:
quibble - we do not understand the criteria by which "named" and
"literal" constants get their own glossary terms
agree with comment - we should consolidate "argument" items in glossary
8.5.8.6 Find better wording for 2nd half of first sentence.
Deferred case is the exception not the common thing.