J3/02-128R1 Date: February 8, 2002 To: J3 From: Dick Hendrickson Subject: Chapter 13, questions about intent and meaning 1) I think the intro to chapter 13 (277:2-16) is confusing about whether or not routines provided in an intrinsic module are themselves intrinsic. Personally, I think a procedure that is part of an intrinsic module is itself intrinsic. But, if it isn't we ought to say so. I don't have a good suggestion because I don't know the answer. Perhaps we just need to say in words that the CH 13 intrinsics are "different" from the Ch 14 and 15 intrinsics. Personally, I think that opens a can of worms. 12.5.1 says a standard conforming program shall not use "intrinsic procedures" other than those from ch 13. What does that mean about the CH 14 and 15 routines? 1.5 bullet (7) seems to imply that only ch13 procedures are "intrinsic". Note 13.1 says that elemental subroutines are PURE and non-elementals are not because they have system side effects (I think CLOCK and RANDOM are the models here). But 14.8.4 says that, for example IEEE_SET_FLAG and IEEE_SET_HALTING_MODE are also elemental. But they have side effects. I think we need to make sure about what we mean about 14 and 15 routines being intrinsic and about the usage of the term "side effects" to describe pure and impure elemental subroutines. This may be harder than I thought. Note 7.9 (page 119) talks about specification subroutines being pure so they don't have side-effects. But in something like DIMENSION(SF1(1) + SF2(2) + SF3(3)) suppose that SF2 invokes one of the elemental (and pure) IEEE subroutines. This will presumably change the behavior of SF1 and SF3 (depending on the optimization level). C1275 allows reference to PURE procedures from within pure procedures and an elemental subprocedure is also pure. Side-effects doesn't appear to be defined other than in NOTE 12.48 The above constraints are designed to guarantee that a pure procedure is free from side effects (modifications of data visible outside the procedure), ... But if IEEE_SET_FLAG is "pure" it can set "global" data that other routines can read via IEEE_GET_FLAG 12.1.2 may be saying that the procedures in 14 and 15 are "module procedures", rather than "intrinsic procedures", but it goes on to say in 242:3 "A module procedure is a procedure that is defined by a module subprogram. A subprogram defines a procedure for the SUBROUTINE or FUNCTION statement..." We don't really expect this to apply to the CH 14/15 procedures. Note 14.1 says ch 14 routines are not intrinsic. I think that should be expanded and made normative. Also, in CH 15, functions like C_LOC are called inquiry functions and "inquiry functions" are one of the four classes of intrinsic function from line 1 of ch 13. Answer: NO action proposed. It was intended that intrinsic module procedures NOT be intrinsic. The text is adequate to cover this; for example, nothing in Ch 13 limits "inquiry functions" to be intrinsic functions. The side effects of IEEE_SET_FLAG will be treated with 02-138. 2) Page 277:8-11. Use of the term "principal argument". I agree with Note 353 on 351. Proposal. 277:8-11 replace for "An inquiry function... is not associated." with "An inquiry function is one whose result depends on the properties of one or more of its arguments instead of than their values; in fact, the argument values may be undefined. Unless the description of an inquiry function states otherwise, the arguments are permitted to be unallocated allocatables or pointers that are not associated." 3) 279:15. The floating point model does not allow for minus zero; are we sure the IEEE functions work on -0.0? Answer: No Action needed. 4) Page 304:16. Is the NAME argument for get_environment_value case sensitive? My recollection is that it is on many operating systems. But OPEN for example is case insensitive. Maybe add a note saying it is or isn't or is proc dependent. Proposal. 304:16 add " The interpretation of case is processor dependent."\ 5) Page 304, STATUS for get_environment_value. Why do we specify 1 and 2 here, but not for the command line functions. It seems to me there are parallel cases for them. No action needed. Command line arguments have more potential exceptional conditions than do environment variables and it's difficult to specify them all. 6) Page 332:4. I don't know what the dangling "are" refers to. To unlimited poly or to unallocated/unassociated? Proposal: page 332:3-4 Replace clause "If either ... both are" by "If A or B is unlimited polymorphic and also either a disassociated pointer or an unallocated allocatable, the result is true if and only if both are unlimited polymorphic and neither is an associated pointer nor an allocated allocatable"