(j3.2006) Tuesday papers
Wed Oct 16 04:39:17 EDT 2013
Herewith comments on Tuesday papers. Sorry I missed Monday's homework.
I have a slight preference for the REQUIRE option, since it is described
in Clause 12. It might be confusing to need to look in Clause 5 under
the rubric IMPLICIT to discover the way to require the EXTERNAL
attribute to be explicitly declared.
In the comment before [176:28-31], "discuss" should be "discussion".
I recently resurrected some 1964 software to compute orbital elements of
meteors observed from two separate locations. It was handy to be able
to execute the code as I revised it, little by little, to make sure I
hadn't broken it. If deleted features actually get deleted from
processors, not just from the standard, this kind of work will become
more difficult and error-prone. Therefore, I have a mild preference not
to remove anything; just leave it in small print, i.e., do nothing at
202 with the present paper, and ask WG5 to remove the requirement.
I don't have 13-008r1 at home, so I didn't check the edit for
[158:33-159:2]. Is there an "or" that ought to be in the obsolescent
part, or has the sentence been rearranged so as not to have "or"
applying to the newly-obsolescent part?
[323:14-324:1-] ought to be [323:14-325:1-]
Add something in the edit for [465:26+] to recommend writing wrappers if
it is necessary for an intrinsic procedure to be an actual argument or a
procedure pointer target.
13-320r1: no comments.
Using GET_TEAM one can effectively assign one team variable to another.
So what is the point of prohibiting team variables from appearing in
variable-definition contexts? If intrinsic assignment is wrong,
presumably a defined one is bound to TEAM_TYPE (but nobody needs to be
told, one way or the other).
In the final comment in the "Discussion" section attributed to me, and
the edit for [29:3+], I think a better solution, which I sent to Bill
via e-mail, is to prohibit a TEAM_TYPE dummy argument from having
INTENT(OUT) (except in a procedure defined in ISO_FORTRAN_ENV -- see my
suggestions for the PROTECTED attribute for types in 13-348). This can
then be a constraint. The edit doesn't cover the case of an actual
argument having a subcomponent of type TEAM_TYPE (which includes the
case of being an extension of TEAM_TYPE).
Under "Discussion - Responses without edits," the reason given for not
gathering the common requirements in one place doesn't address the
commonalities between the cases; rather it addresses the differences.
Again, see 13-348, which covers only the commonalities (and one more
thing not germane to types having no public components). Even if J3
doesn't wish to ask WG5 for permission for a PROTECTED attribute for
types, most of the material in 13-348 (i.e., except for the last bullet
in the proposed C552a) would be useful for describing the common
requirements in one place instead of three. That constraint could be in
13.8 with an introduction something like "If [the definition of?] a type
is accessed from ISO_FORTRAN_ENV by use association...."
Is it necessary to say, or does it already say somewhere, that
LOCK_TYPE, EVENT_TYPE, and TEAM_TYPE are not SEQUENCE or BIND(C) types?
13-343r2: No comments.
In the edit for the intro, change "F descriptor" to "F and G edit
There should be an explicitly-named value of the STAT= variable in a
CHANGE TEAM statement to indicate that the team variable does not
describe a valid team.
More information about the J3