Re: F2008 draft

On Mon, 17 Jul 2006 09:34:33 -0700, Joe Krahn wrote
(in article <t_Oug.3$uk2.0@xxxxxxxxxxxxxxxxxxx>):

It looks like the draft of F2008 is available at J3:
http://j3-fortran.org/doc/year/06 files 06-007.*

Does anyone here have an idea when the public comment period will be?
Are non-member comments accepted before then?

I haven't been keeping up with the f2008 schedule details; I'll let
others comment. As for whether non-member comments are "accepted",
well, I can't really comment on that either. You can *ALWAYS* send
something in, and there is not actually a distinction between member vs
non-member. As to whether you can succeed in selling an idea, that's a
much harder question to answer.

I would speculate that you'd have a hard time selling new proposals
right now unless you had awfully strong justification. "Would be nice"
doesn't come particularly close to being awfully strong. These all look
like "would be nice" things to me. But that's just my personal guess
and I've been wrong on such things before - sometimes wrong by quite a
lot.

One thing I see is a new block construct that includes a specification
section: BLOCK ... END BLOCK. I wonder why not just allow a
specification section in the current block constructs?

This has been debated - at some length actually. The short answer is
that the answer isn't short. :-)

That's because you are focusing on a syntax issue - placement of
declarations. The syntax part is trivial. What is much more
fundamental is that you have introduced a new kind of scoping unit.
That has *LOTS* of implications. I'm not saying it can't happen, but I
will say that one of the best ways to kill a proposal is to severely
underestimate its impact when selling it. When something turns out to
be an order of magnitude more complicated than it was sold as, it has a
high probability of getting dropped; far better to acknowledge the
complications up front (ideally with proposed ways of dealing with
them).

Among the issues:

Lifetime of variables declared in a block. Do they "go away" when the
block exits? Can they be SAVE'd? Can they have an intermediate form of
SAVE that makes them last until the procedure exits?

All the complications of host association come into play. A "favorite"
is implicit typing. If you can have explicit declarations in such a
block, can you also have implicit ones? If not, you have a funny
inconsistency. If so, you have the possibility of implicitly declared
variables ending up in lower scopes than intended.

These questions can certainly be worked. But they have to be. That's
probably 90+% of the work involved in doing something along these
lines, so failing to at least bring up the question would probably come
over (in my opinion) as reflecting an inadequately thought through
proposal... and a poor candidate for a late addition. When a proposal
shows evidence of overlooking something major, that naturally raises
the question in many people's mind of what else it might have also
overlooked, thus suggesting that perhaps it needs more review time than
late additions have available.

For now, you can use: DO ... EXIT; END DO

I've seen this idea before and I personally strongly recommend against
using that form for a "do once". I consider it to be a "hack", and it
shares many of the problems of such things. It is confusing and
extremely error prone. Fundamentally, DO is a looping construct. In
this particular case, you are even using an infinite loop form if it,
counting on the exit to make it do what you really want. It is
confusing because the reader sees the infinite loop and has to look
inside to understand that it can never actually loop. It is error prone
because accidentally omitting the exit (as could happen any number of
ways) completely changes the nature of it; you then have that infinite
loop.

To me, this "solution" is far more objectionable than just using a
plain old-fashioned GOTO. Yes, I know about the potential problems of
that; but to me they are dwarfed by the even larger problems of this
hack.

--
Richard Maine | Good judgment comes from
experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

.