(j3.2006) [Fwd: C501 in TS 18508]

[Van Snyder]

On Wed, 2013-03-06 at 09:19 +0900, Malcolm Cohen wrote:
> I don't understand "efficient".  Efficient in what way?  Do you mean
> economical with ink and/or paper?  Uses fewer integers for constraint
> numbers?

Having fewer nearly identical constraints is rather different from
having fewer constraint numbers.  Saying something once is better than
saying essentially the same thing three times.  The latter invites
divergence to inconsistency or incorrectness.

> Or are you saying it would be easier to understand?

Both.

> From John's message it would appear that he thinks it is easier to
> understand the way that CHANGE TEAM works by having the constraints
> there rather than elsewhere, and I can see his point.

Well then let's split C821 and C845 into two pieces, one each under the
CRITICAL rubric and another two under the DO CONCURRENT rubric, and add
two more under the CHANGE TEAM rubric.  Would six constraints be clearer
than two?

Given that the constraint concerning the use of EXIT within CRITICAL and
DO CONCURRENT is C845, not two essentially identical constraints under
the CRITICAL and DO CONCURRENT rubrics, I prefer to expand that
constraint to cover CHANGE TEAM, rather than to have an essentially
identical one under the CHANGE TEAM rubric.  Similar observations apply
to CYCLE (C821).

I don't like the helter-skelter style of partially constraining the use
of EXIT and CYCLE within CRITICAL and DO CONCURRENT constructs in
discussions of the EXIT and CYCLE statements, further constraining their
use within CHANGE TEAM constructs under that rubric, and constraining
the use of RETURN and branching thrice each within the descriptions of
the CHANGE TEAM, CRITICAL, and DO CONCURRENT constructs.  This makes the
standard look like a stream-of-consciousness hex dump rather than an
organized document.

I believe it would be better to expand the constraints on EXIT (C845)
and CYCLE (C821) to cover what was overlooked in TS 18508,

"C845 An <exit-stmt> within a DO CONCURRENT construct shall not belong
      to that construct or an outer construct; an <exit-stmt> within a
      CHANGE TEAM or CRITICAL construct shall not belong to an outer
      construct."

(this is a slight extension to C845 as it presently stands; it allows
EXIT to apply to a CRITICAL construct, rather than expecting to put a
statement label on the END CRITICAL statement and branch to it, or
enclosing the <block> of the CRITICAL construct in a BLOCK construct and
exiting the BLOCK; this is how Bill expressed a desire for EXIT to work
for the CHANGE TEAM construct)

"C821 (R831) A <cycle-stmt> within a CHANGE TEAM, CRITICAL, or DO
      CONCURRENT construct shall not belong to an outer construct."

have one constraint (in 12.6.2.7) of the form

"C1269a A <return-stmt> shall not appear within a CHANGE TEAM, CRITICAL,
        or DO CONCURRENT construct."

and a similar one (in 8.2.1)

"C845a A branch within a CHANGE TEAM, CRITICAL, or DO CONCURRENT
       construct shall not have a branch target that is outside the
       construct."

rather than to have four sets of three essentially identical
constraints, scattered amongst the descriptions of each of those
constructs.  It's bad enough already having two (C810, C822) for RETURN
and two more (C811 and C824) for branching, where one each would do, and
then needing to add three more to cover that we overlooked EXIT, CYCLE
and RETURN in TS 18508.

Would twelve constraints be clearer than four?  How about ten: one on
EXIT that covers CRITICAL and DO CONCURRENT and one on CHANGE TEAM that
covers EXIT, one on CYCLE that covers CRITICAL and DO CONCURRENT and one
on CHANGE TEAM that covers CYCLE, and two each on CHANGE TEAM, CRITICAL
and DO CONCURRENT that cover RETURN and branching?