Re: F2008 draft

Richard Maine wrote:
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.
I know that much of F2008 feature decisions are fairly fixed now. One thing I am wondering is whether public ideas from the public comment period have a chance at consideration even if it is a bit late for suggesting the idea internally. In other words, is the public comment period really useful for public comments, or is it generally too late to be useful anyhow, other than giving some ideas for the future?



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.
OK; this makes sense. The BLOCK syntax also defines boundaries for implicit variables, which cannot be done for all block constructs without backwards compatibility issues.


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.

I have not used it a lot for those reasons. It is a bit more clear if started with a comment as "DO !ONCE". Maybe "DO unused=1,1" would be better, but still a hack. I would like the GOTO approach better if I could use name labels in addition to numeric labels. Now that assigned-goto is gone, it might be easy to support, but there is always a chance of a syntax conflict.

One nice alternative is to put the block into an internal subroutine. I still think a proper DO-ONCE would be nice, even though I have not seen it in an existing language.

Thanks,
Joe Krahn
.