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?