(j3.2006) Locality problems not repaired at Garching

[Malcolm Cohen]

<<<
This rests upon a deeper question that might be addressed
somewhere, but I couldn't find an answer:
>>>

And yet in the February meeting the normative text was quoted in response to 
this non-deep question.

<<<
If an implicitly-declared
variable appears only within a BLOCK construct (or several disjoint
ones), is it a construct entity of that (those) BLOCK construct(s)?
>>>

Obviously not, since we state
  "An entity that is explicitly declared in the specification part of a 
BLOCK construct, other than only in ASYNCHRONOUS and VOLATILE statements, is 
a construct entity."
Note that this does not include implicitly-declared entities.

In 19.1, we state clearly
  "The scope of ... a local identifier is an inclusive scope,..."
and you will recall that inclusive scope is
  "nonblock scoping unit plus every block scoping unit whose host is that 
scoping unit or that is nested within such a block scoping unit"

i.e. everything acts as if BLOCK constructs were not scoping units 
***except*** for the things explicitly declared within the BLOCK construct. 
For further example, BLOCK constructs can refer to labels outside the 
construct, and outside a BLOCK construct one can refer to a label inside the 
construct (only validly for FORMAT since it's still prohibited to jump into 
any block).  Similarly for construct names (only useful for EXIT/CYCLE).

The whole point of the BLOCK design was to allow people to insert 
BLOCK-ENDBLOCK when they wanted to add an explicitly declared construct 
entity to some existing code, without distrubing the semantics of the 
existing code.

I note that if BLOCK affected implicitly declared entities, it would be 
extremely error-prone to add to existing code, and indeed if that were the 
case BLOCK would have been an extremely bad construct.  Fortunately, that is 
not the case, BLOCK has no effect on implicitly declared entities.

Cheers,
-- 
..........................Malcolm Cohen.