(j3.2006) statement labels and scope
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
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
(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
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"
(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