(j3.2006) statement labels and scope

Cohen Malcolm malcolm
Thu Jan 14 22:01:56 EST 2016

Bill Long writes:
>BLOCK constructs are scopes

No they are not.  They are "scoping units".

The scope of an identifier can be the entire program, a scoping unit, an 
inclusive scope, a construct, a statement, or a part of a statement. 
Whatever that is, is its "scope".

So a BLOCK construct is not "a scope", but it can be "the scope" of the 
identifier of a construct entity.

Moreover, as you quote the text is
  "The same statement label shall not be given to more than one statement in 
its scope."
This says nothing at all about what the scope of a statement label *IS*, it 
just says that it must be unique within "its scope", whatever that might 
happen to be.

This is basic language: "scope" is always the scope "of something".  There 
is no such thing as "a scope" in isolation; for that we have "scoping unit", 
"inclusive scope", "scope of a statement", etc..

>> Subclause 16.3.1 says that statement labels are local identifiers.
>unless they are construct entities.

No, that would be unless *statements* are construct entities (a statement 
label is an identifier of a statement).

16.3.1 does seem to mix these up, it says "Identifiers of entities ... 
except for statement or construct entities ... are local identifiers".  The 
only thing is, it lists "statement labels" as the entities, instead of 
"statements"; obviously wrong since we don't have an identifier that 
identifies a statement label that identifies a statement, the statement 
label *is* the identifier and "statement" is the entity.  Both 1.3.138 and 
16.1p3 get this right.

That is, a statement label is an *identifier* of an entity which is a 

And statements are not "construct entities".  They are just statements.  You 
do not declare or specify a statement, so by 16.4 and 16.3.1 statement 
labels are local identifiers.

8.1.4 says that "specifications in a BLOCK construct declare construct 
entities", no mention is made of any effect on statements.

Also consider C930 (p220) which states
  "The label shall be the label of a FORMAT statement that appears in the 
same inclusive scope as the statement containing the FMT= specifier."

Thus statement labels must have inclusive scope, otherwise this constraint 
is nonsense.



(1) BLOCK constructs were originally not scoping units at all, we just made 
all the specification statements therein produce construct entities.  The 
change to call them scoping units was an editorial change *without any 
intended technical effect* (the paper that did this, 10-126r1, contains only 
edits no specs/syntax); the editorial change was to simplify the description 
throughout the standard.

(2) The user is supposed to be able to add BLOCK-ENDBLOCK around any block 
of code with no effect (as long as there is no branch into the block).  This 
is basic design from the original spec for macros, where it is absolutely 

(3) We also wanted to leave the door open to potentially allowing a 
<block-specification-part> in any <block>, not just a BLOCK construct, as a 
future extension.  This absolutely requires "inclusive scope" for statement 
labels as well as implicitly declared variables.


>So, we conclude that either 3.2.5 or 16.4 is wrong.

Since 3.2.5 says nothing whatsoever about what the scope of a statement 
label is, it cannot contradict 16.4.

I would prefer to let 3.2.5 continue to say nothing about the scope of a 
statement label.


Since it seems that this is not clear enough to avoid misunderstanding, we 
could add some clarifying words somewhere, either as a note or as normative 
text (given that statements are not construct entities, normative text is 
not actually needed).

E.g. we could

(a) add a remark that a "statement label is always a local identifier" to 
(b) add a remark that a "statement is never a statement or construct entity" 
to 16.4,
(c) add a remark that "the scope of a statement label is always inclusive 
scope" to 3.2.5.

In any case, we ought to fix 16.3.1p1 "statement labels" -> "statements".

........................Malcolm Cohen, Nihon NAG, Tokyo. 

More information about the J3 mailing list