J3/04-417 To: J3 Members Date: 20-Sep-2004 From: /interp/Stan Whitlock Subj: Results of the F95 interp letter ballot #8 Here are the results of J3 letter ballot #8 on Fortran 95 interpretations that closed on 16-Aug-2004. The ballot is in J3 paper 04-364. If I have transcribed a vote or a comment incorrectly, please let me know. Note that interp 31 was subsumed by 74 and interp 98 is a duplicate of 6; they are listed here for completeness. J3 rep 4 6 8 17 23 30 31 68 74 78 96 98 102 Rich Bleikamp no ballot received Dick Hendrickson no ballot received Michael Ingrassia Y Y Y Y Y Y SS Y Y Y Y D Y Rob James Y Y Y Y Y N SS Y C Y Y D N Bill Long Y Y Y Y Y Y SS Y Y Y Y D Y Jeanne Martin no ballot received Dan Nagle Y Y Y Y Y Y SS Y Y Y Y D Y Craig Rasmussen excused Van Snyder Y Y Y Y Y Y SS Y N Y Y D Y Matthijs/Toon Y Y Y Y Y Y SS Y Y Y Y D Y Stan Whitlock Y Y Y Y Y Y SS Y Y Y Y D Y J3 rep 103 104 F90 F90 F90 F90 F90 F90 F90 F90 F90 JP 49 70 96 140 180 206 207 208 210 24 Rich Bleikamp no ballot received Dick Hendrickson no ballot received Michael Ingrassia Y Y Y Y Y Y Y Y Y Y Y Y Rob James Y Y Y Y Y Y Y Y Y Y Y Y Bill Long Y Y Y Y Y Y Y Y Y Y Y Y Jeanne Martin no ballot received Dan Nagle Y Y Y Y Y Y Y Y Y Y Y Y Craig Rasmussen excused Van Snyder Y N Y Y Y Y Y Y Y Y Y Y Matthijs/Toon Y Y Y Y Y Y Y Y Y Y Y Y Stan Whitlock Y Y Y Y Y Y Y Y Y Y Y Y where Y means "yes" C "yes with comment" N "no with comment" SS "subsumed" D "duplicate" The comments are attached below in the same order as the table above. The summary of DRAFT results is as follows: P = passed C = passed as amended F = further consideration 4 6 8 17 23 30 31 68 74 78 96 98 102 P P P P P F SS P P P P D F 103 104 F90 F90 F90 F90 F90 F90 F90 F90 F90 JP 49 70 96 140 180 206 207 208 210 24 P P P P P P P P P P P P The interps marked "C" pass with some minor typo fixes, as noted below. The interps marked "F" will be reconsidered at J3 meeting #170 by the /interp committee who will decide if the status becomes "withdraw for more work", "passed as amended", or "passed as printed". /Stan ************************************************************************ 000030 Ordering requirements on definition of specification functions Rob James' NO comment on 000030: The proposed interpretation is too restrictive. One could imagine a situation in which a user might want to use a generic interface to specify bounds for array dummy arguments for module procedures. The user would then be restricted to putting the specific procedures for that generic immediately after the module's specification part. This restriction would seem very arbitrary to the user. Take the following example: module mod1 interface dummy_extent module procedure integer_dummy_extent module procedure real_dummy_extent end interface contains subroutine do_something(a) integer :: a(dummy_extent(0)) ... end subroutine subroutine do_another_thing(b) real :: b(dummy_extent(0.0)) ... end subroutine ! For procedures in this module, we know that all integer dummy ! arrays will have extent 10 and all real dummy arrays will have ! extent 5, so let's provide procedures so that we don't have to ! remember those numbers specifically. And while we're at it, ! we might as well put them in an out-of-the-way place at the ! bottom of the module. pure function integer_dummy_extent(x) integer :: integer_dummy_extent, x integer_dummy_extent = 10 end function pure function real_dummy_extent(x) real :: real_dummy_extent, x real_dummy_extent = 5 end function end module 000074 TARGET dummy arguments and POINTER expressions Rob James' YES comment on 000074: I believe that the example given should ideally be standard-conforming, but I agree with the interpretation in that I don't think we should be kludging this functionality into the current standard. For the next revision of the standard, I believe that we should try to make this example standard-conforming. Van Snyder's NO comment on 000074: The reasoning for the answer to Interpretation 74 is flawed. The conclusion cannot be support by the cited passages. The first justification given, from 12.5.2.1, is that "A dummy data object whose intent is not specified is subject to the limitations of the data entity that is the associated actual argument.  That is, a reference to the dummy data object may occur if the actual argument is defined and the dummy data object may be defined if the actual argument is definable." The reasoning continues "Here the actual argument is a function result, which is not definable." The quote is accurate, but the conclusion is wrong because the quoted passage has nothing to do with the question: The actual argument is not the function result; it is the target of the function result. See [269:20-22] in the DIS ([200:30-32] in F95): "If the dummy argument is not a pointer and the corresponding actual argument is a pointer, the actual argument shall be associated with a target and the dummy argument becomes argument associated with that target." Similarly, the reasoning for question 2: "The call to s2 is not standard conforming. 12.4.1.1 says: 'If a dummy argument has INTENT(OUT) or INTENT(INOUT), the actual argument shall be definable.' "Again the actual argument is a function result, which is not definable." is not probitive, because the actual argument is in fact not a function result. That is, the quoted passage cannot logically be used to support the conclusion. Consider the following program program P real, target :: A = 42.0 real, pointer :: P p => a call s ( f(p) ) contains subroutine S ( X ) real :: X ! or INTENT(OUT) or INTENT(INOUT) print *, x end subroutine S function F ( Y ) real, pointer :: F real, pointer :: Y f => y end function F end program P It is clear that A is pointer associated with P. The dummy argument Y of the function F is argument associated with P, not with A. The result of F is a pointer associated with A, not A itself. The result of F is a pointer associated with A. X is not a pointer. Therefore, the actual argument of S is the target of P, that is, A, which is NOT the result of F. That is, the actual argument is not the result of F. The conclusion should be "This program is standard conforming. The actual argument is not the result of the function F, but rather the target of the result of F. It is the target of the result of F that is argument associated with the dummy arguments of S1, S2 and S3. See 12.4.1.1: 'If the dummy argument is not a pointer and the corresponding actual argument is a pointer, the actual argument shall be associated with a target and the dummy argument becomes argument associated with that target.' "Therefore the passage from 12.5.2.1: 'A dummy data object whose intent is not specified is subject to the limitations of the data entity that is the associated actual argument. That is, a reference to the dummy data object may occur if the actual argument is defined and the dummy data object may be defined if the actual argument is definable.' does not apply. "If a pointer is associated with a data entity, that is, if it has a target, its target is definable. Therefore, since the data entity that is the actual argument of S1 or S2 is definable, the dummy arguments of S1 and S2 are definable." That the target of the function result is the actual argument should be obvious from the following embellishment of the above program: program P real, target :: A = 42.0 real, pointer :: P1, P2, P3 p1 => a p2 => f(p1) print *, associated(p1,p2) ! Prints "T" print *, p1, p2 ! Prints "42.0 42.0" call s ( p1 ) ! Obviously permitted. Target of P1 is actual arg. call s ( p2 ) ! Obviously permitted. Target of P2 is actual arg. call s ( f(p1) ) ! The bone of contention contains subroutine S ( X ) real :: X ! or INTENT(OUT) or INTENT(INOUT) print *, x end subroutine S function F ( Y ) real, pointer :: F real, pointer :: Y f => y end function F end program P Richard Maine has lectured us for many years about the distinction between a pointer and its target. His lessons are particularly germane here. I agree that no edits are needed for interpretation 74. 000102     mask-expr evaluated only once Rob James' NO comment on 000102: I don't believe that the first edit is correct. It applies to a WHERE, not an ELSEWHERE. For a WHERE, I believe that evaluation of the mask expression is necessary if the WHERE is executed. I do agree, however, that it is not necessary to evaluate the mask expression of an ELSEWHERE in all situations. 000104     Representation method of result of REAL Van Snyder's NO comment on 000104: The reasoning for the answer to Interpretation 104 is flawed. The conclusion cannot be support by the cited passages. The answer does not address the questions. The cited passage from subclause 1.4, viz.   "This standard does not specify ...    (6) The physical properties of the representation of quantities and the method of rounding, approximating, or computing numeric values on a particular processor, ...." is not germane to the cardinality of the correspondence between kind and representation. The germane subclause is 4.3.1.2: "A processor shall provide two or more approximation methods that   define sets of values for data of type real. Each such method has a representation method and is characterized by a value for a type parameter called the kind type parameter." This specifies that there is ONE representation method and ONE kind type parameter value for each approximation method. The cited passage from subclause 1.4 says that a processor is free to choose what EACH representation method is, and how crappy the arithmetic can be. It does not contradict the assertion in 4.3.1.2 that each approximation method corresponds to exactly ONE representation method, and it therefore cannot be used to support the conclusion that several representation methods are allowed for the result of a function, depending on the context of an appearance of a reference to it, or the whim of the processor. The "logic" applied to this interpretation, resting solely on item (6) from 1.4, could be construed to allow the result of DBLE(0.1e0) to have the same representation as 0.1e0. This is clearly undesirable, especially where the function result is an actual argument, and illustrates the absurdity of the conclusion. It may be viewed as an unfortunate consequence of a conspiracy of 7.1.4.2 and 4.3.1.2 that the sorts of exceedingly useful optimizations that processors commonly do are prohibited, in particular, that they are apparently prohibited to use an intermediate result in a floating-point register if that register has a different representation method from constants or variables of the kind demanded by 7.1.4.2. The edits proposed in 04-283 were intended explicitly to allow multiple representations for intermediate expression results, but not for the results of the REAL and CMPLX intrinsic functions, so as to make these obviously useful optimizations legal. We need to reason from what the standard says, not backward from the desired result using faulty logic to justify it. If the standard cannot support what we want it to support, it has to be amended; we cannot wish away difficulties by using irrelevant quotations.