(j3.2006) Tuesday papers

Van Snyder van.snyder
Wed Oct 16 04:39:17 EDT 2013


Herewith comments on Tuesday papers.  Sorry I missed Monday's homework.

13-312r2:

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.

13-317r2:

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.

13-319r1:

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.

13-333r2:

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).

13-335r2:

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.

13-351r1:

In the edit for the intro, change "F descriptor" to "F and G edit 
descriptors".

13-354r1:

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 mailing list