Re: Nested Declarations

Tim Prince <tprince@xxxxxxxxxxxxxxxxxx> wrote:

PGK wrote:
[asks for what is probably the f2008 block construct]
And you want the ability to generate broken code such as we often see in
C++ applications, where the programmer makes a different choice from the
standard about the point where the inner declaration goes out of scope?

Ah yes. I don't know C++, but recollections of some Fortran issues are
begining to come back. Multiple places in the Fortran standard
specifically list things that can make something go out of scope. I'm
thinking in particular of places that talk about events that can happen
as a result of a return or end statement. As per my usual, I would
rather these have talked a little more abstractly instead of about the
particular bits of syntax that can currently make it happen.

I wonder whether they all got found and fixed in introducing BLOCK to
f2008. Ah heck. I'll go grab a current copy of the draft and take a look
while I'm still waking up. Hmm... Maybe I'm not yet awake enough, but it
doesn't look good. Looks like exactly the kind of thing where something
got put in without thinking about all the ways it interacted with the
rest of the standard. Granted, I'm skimming, so I could have missed
major stuff. I have the CD dated 25 March 2009. That's what I found on
the J3 site. Let's see...

First, a sanity check on something that would change lots of things.
Such a block is not a scoping unit (1.3.113).

The section on the block construct itself (8.1.4) says that the
specifications in it declare construct entities, whose scope is the
construct. THat's pretty much all it says, though.

Hmm. That makes me wonder about implicitly declared things that don't
have specifications. Ok, the old words in 5.5, para 4 (I like the new
paragraph numbering - makes citation easier) seem to cover that ok.
Looks like implicit declarations always declare things to have the scope
of a scoping unit - never a construct. Not sure whether that was thought
about or just happened that way. Guess I don't see a problem; at least
it is clearly (to me) specified.

On to clause 16, where I expected much of the meat. 16.4 is the
subclause about statement and construct entities. Oh dear! It says
almost nothing useful here. It verifies that things declared in a block
construct are construct entities, and there is all the general material
about how construct entities override host associated or global ones.
But I don't see *ANY* material on all the interesting questions. The
other kinds of construct entities were all so limited that most of the
questions didn't come up. We still have the simple rule that two
construct entities cannot have the same identifier. How about some of
the rules in 16.3.1; those are different in block constructs? For
example, you can't have a derived type the same name as a procedure or
any of the other exceptions to the simple rule? Admitedly some of those
exceptions are a bit messy, but it seems even messier to allow them some
places but not others. Construct entities are specifically excluded from
the list of local identifiers discussed in 16.3.1.

Heck, I'd look for just about any appearance of the term "scoping unit"
as having potential problems. Alas, there are a lot of appearances of
that term. That's because the block construct introduces something that
is a lot like a scoping unit, but isn't one. Maybe it really should be
one. That might solve a lot of those problems. But then it might
introduce others.

Hmm. You don't have host association into blocks. I suppose that's
because they are not scoping units and so don't need it. But I sure
wonder how it manages to get by without at least some of the material
related to host association. Oh, for a messy example, can you declare a
generic in a block? I can't think of why not... except that the
complicated rules for generic resolution are all tied into host
association and scoping units (12.5.5).

There at least does appear to be some attention given to talking about
when construct variables become undefined (16.6.6(22)). I note a
difference between (22) and (3) in the same list, though,...

Which brings me back to something else I skipped over before - COMMON
blocks. I can't figure out what would be going on with those. None of
the material about common blocks appears to have anything about teh
block construct added. looks like common blocks are still all described
in terms of scoping units that reference them (including the bit in
16.6.3(3) about undefinition when going out of scope). I see multiple
contradictions here. Does a common statement in a block extend a common
statement for the same common name outside of the block? That doesn't
make much sense. Does it declare a separate instance of the common
block? That would seem more consistent with many things, except for all
the places where common blocks are tied to scoping units.

Can there be automatic objects in a block? I'm looking at 16.6.5(21) and
noting that it seems to assume that an automatic object must belong to a
procedure.

Well, that's (quite a lot more than) enough on this. I have to go do
some real work. This was all from just a fast skim through the CD. I
could possibly have missed a few things that fix it all. But I'm
guessing that the opposite is true - that when the BLOCK construct was
added people skimmed for places that they thought needed corresponding
modification, but they missed the hard fundamental ones. I think the
result is pretty much unrescuable.

I think the most fundamental question is whether a block is or is not a
scoping unit. Either answer makes for a mess, though the resulting
messes are different. There is just to much material that refers to
scoping units.

I'm betting that this kind of problem was why block constructs got
rejected in prior standards. Apparently it got reproposed and accepted
without the same degree of scrutiny as before. I'm surprised Malcolm
didn't catch this. Of course, maybe he did and got outvoted.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
.

Relevant Pages

  • Re: Array Constructors
    ... even those with statement or construct level scope. ... you have to declare the variable in the scoping unit. ... an array constructor is always scalar. ...
    (comp.lang.fortran)
  • Re: UML Design and associations
    ... It is common for me to have one ... For instance, class A has a method called Method1, and inside ... I declare and create an instance of Class B. Together and other ... > because Class B is declared to have scope only within Method1. ...
    (comp.object)
  • Re: Garbage collection problem
    ... The whole point of optimization is to ... > same camp as Chris Smith on the matter. ... declare a scope for the variable I may be depending on the object remaining ...
    (comp.lang.java.programmer)
  • Please advise of basic problem in my code (using opendialog)
    ... Thankyou for your time Olie, I do understand the basics of classes, but ... One of those principals is variable scope. ... In your example you declare file in the function Form1_Loadbut this ... private void Form1_Load ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Java needs "goto" (was Re: hi)
    ... cause they won't go out of scope. ... as if they are hit, you are COMPLETELY out to lunch, ... that exception was hit if you are using declarations ... so a "declare at the top" style should still yield to ...
    (comp.lang.java.programmer)
Loading