07-239 To: J3 From: Van Snyder Subject: Comments on Clause 7 revisited from 180 Date: 2007 July 05 Reference: 07-190r3 07-190 recommende3d 07-007r1:142:11-22 (07-007r2:154:11-22) [It is confusing and verbose to say that the operation involves the specified list of operators, and then say that the operator is the operator in the operation. Why not define the operators first, as at [142:23-30]? Editor: Replace the paragraphs:] A <> is +, -, *, /, or **. A <> is an intrinsic operation for which the is a numeric intrinsic operator and the operands are of numeric type. The <> is //. The <> is an intrinsic operation for which the is a character intrinsic operator and the operands are of type character. A <> is .AND., .OR., .XOR., .NOT., .EQV., or .NEQV.. A <> is an intrinsic operation for which the is a logical intrinsic operator and both operands are of type logical. A <> is //, .AND., .OR., .XOR., .NOT., .EQV., or .NEQV.. A <> is an intrinsic operation for which the is a bits intrinsic operator and at least one operand is of type bits. ------------------------------ 07-007r1:142:23 (07-007r2:154:23 delete "an that is " The editor commented - DEFERRED [142:11-22]. This completely changes what the various kinds of intrinsic operator are. I'll probably end up rejecting it. - [142:23] Ditto. I'm curious how the proposed edits change the nature of intrinsic operators. -------------------------------------------------------------------------- 07-190 recommended 07-007r1:171:2 (07-007r2:184:4) Do we need "and forall-triplet-spec " after "scalar-mask-expr "? 07-190r3 answered Answer: No. There is the general requirement that functions are not allowed to have side-effects on anything in the statement they appear in. This brings the question "Then what is the point of 07-007r1:C746 (07-007r2:C740)?" Either add "and forall-triplet-spec" or delete the constraint. 07-190 recommended 07-007r1:144:2-3 (07-007r2:144:2-3) [Doesn't belong here; probably shouldn't even be normative. Editor: Delete the paragraph.] 07-190r3 moved it to the "Edits not done" section witout comment. The reason it doesn't belong where it's cited is that it's about evaluation, not interpretation. If it should be normative, then so should all of Note 7.19. Since Note 7.19 isn't normative, this shouldn't be either. -------------------------------------------------------------------------- 07-190 recommended 0-007r1:144:4-12 (07-007r2:156:4-12) [Why is [144:4-9] so long winded? Editor: Replace the paragraph:] If both operands of a division operation are integers the result q is the integer such that x1 / x2 = q + r where r is an integer such that 0 <= |r| < |x2| and the sign of r is the same as the sign of q . [Then move 7.1.5.2.2 and 7.1.5.2.3 to [07-007r1:145:3- (07-007r2:158:1-)].] 07-190r3 moved it to the "Edits not done" section witout comment. Even if the paragraph is not revised, the subclauses ought to be moved because they are about evaluation of particular numeric intrinsic operations, not interpretation. As such, they ought to be discussed after the general discussion of evaluation of numeric intrinsic operations. -------------------------------------------------------------------------- 07-190 recommended 07-007r1:145 (07-007r2:157): Note 7.19 [insert the following after "A / 5.0":] A ** B 1/(A ** (-B)) A ** B (1/A) ** (-B) For integer A and B with nonzero A and negative B, either of the last two alternative forms show that the result is zero. The final alternative form is not recommended for real A if B is large and sufficiently negative that log2 |B| is greater than the number of guard digits. Subgroup comment: The result is not zero if ABS(A) = 1 This goes with the proposal to delete 07-007r1:142:2-3. Instead of not doing the edit replace the explanation by "For integer A and B with |A|>1 and negative B, either of the last two alternative forms show that the result is zero. The final alternative form is not recommended for real A if B is negative and log_r |B| is greater than the number of base-r guard digits. -------------------------------------------------------------------------- 07-190 recommended 07-007r1:155:20-21 (07-007r2:167:2-3) [Editor: Insert "an initialization expression or" before "an expression", insert "or defined by a specification function" after "intrinsic" (this is a little bit of feature creep), delete item (1) from the list.] 07-190r3 moved it to the "Edits not done" section witout comment. It wouldn't hurt to make it clear that initialization expressions are a subset of specification expressions, instead of requiring the reader to prove a theorem. See UTI 122. If we agree that it's reasonable to access intrinsic functions such as ALLOCATED directly rather than needing to disguise them within specification functions, what's wrong with accessing specification functions by way of defined operations? -------------------------------------------------------------------------- 07-190 recommended 07-007r1:156: Note 7.34 (07-007r2:169: Note 7.33) [Creating a new instance while construction of one is in progress shouldn't really be a problem. The real problem is that the recursion can't stop. Editor: Replace "The prohibition . . . progress" by "Recursion would not terminate and therefore is prohibited".] What's wrong with correcting a note?