[Patch/fortran] Add documentation section about implemented F2003 features

[Richard E Maine]

On Aug 2, 2005, at 11:43 PM, Janne Blomqvist wrote:

> F95 automagically deallocates non-saved allocatables when
> they go out of scope. In F90 it is the responsibility of the
> programmer to remember the deallocate.

That doesn't mean that an f90 compiler won't do the deallocation; that 
just means that the standard doesn't specify it.

> Practically speaking, I guess the usual
> implementation of F90 allocatables would imply leaking the memory and
> continuing happily,

No. I disagree - vehemently. You miss my main point. The usual 
implementation of f90 allocatables today is identical to that of f95 
allocatables. Although the f90 standard doesn't require it, the f95 
working is a valid implementation of the f90 standard. I'm quite 
confident that it is the most common implementation today, since most 
compilers today are f95 ones. There *IS* no other canonical f90 
implementation that is normally expected by f90 users.

Even before f95, my experience was that the usual implementation was to 
give an error if you tried to do anything subsequently with the 
variable. I personally observed this happening with at least some 
implementations. I could imagine the possibility of implementations 
that effectively treated allocatables as saved, though I don't recall 
for sure whether any worked that way. I somewhat doubt that there were 
ever *ANY* implementations that leaked memory in the fashion that you 
mention. Such implementation would have been allowed by the standard, 
and it is possible that there was one somewhere, but it certainly was 
not a "usual" implementation in any sense of the word.

> I personally can't see a single reason why an
> F90 allocatable in the undefined status would be beneficial.

Me neither. Not have I ever heard of anyone that does.

> Say, an inexperienced programmer is ordered by his boss
> to write a Fortran program, picks up a Fortran 90 book somewhere,
> looks at the gfortran man page and sees that we have a -std=f90
> switch, starts programming and at some point forgets to deallocate an
> allocatable and later tries to access it again. Well, there we have
> WWIII.

I see that I am not communicating my point. I am not asking for 
implementation of some different scheme. I am telling you that the 
scheme you have right now *IS* a valid f90 implementation. It is the 
most common f90 implementation today, and is the preferred one. So what 
happens to that programmer is that he gets the f95 scheme and his array 
is automatically deallocated. Nothing in the f90 standard actually 
requires WWIII. The whole point of "undefined" is that it is up to the 
compiler what to do. Compilers today sensibly choose to do the f95 
thing.

Recall that  just like undefined variable values (way back to f66), 
"undefined" is not a testable state. When the standard says that 
something is undefined, that never lays a requirement on a compiler. 
That translates to "the compiler can do whatever it darn well wants". 
Perhaps a better wording would be "undefined by the standard" which is 
not at all the same thing as "undefined by the compiler".

> So he thinks
> that .f90 means the program is F90, looks at the man page and enables
> the -std=f90 option. Well, what if the program in fact was F95 and the
> programmer hasn't bothered to deallocate as he knows that the compiler
> will take care of it (that's what I personally do, for example)? WWIII
> again?

Nothing different at all will happen because a std=f90 option won't 
affect allocatable treatment in that way. It would make no sense at all 
for it to, and I seriously doubt that any compiler anywhere would do 
that with a std=f90 option.

Misuse of allocatables like that isn't even one of the things that the 
standard mandates diagnosis of, so the std=f90 switch probably has no 
effect here at all. If someone really, really wanted to go to special 
effort to try to verify 90 compliance even at run-time, then I could 
imagine that one *MIGHT* implement it so that you would get an error 
message. The only purpose of that would be to help enforce f90 
compliance - not to help non-compliant programs run. An error message 
is what some pre-f95 compilers did. I don't know that any f95 compilers 
tie such a message to a std=f90 switch; I'd guess not, but it is at 
least plausible. Seems like extra work for minimal gain. I can imagine 
no reason at all why any f95 compiler would even have an option to do 
anything other than the standard f95 thing or an error message. That 
would be truly odd. Have you *EVER* seen such a thing or are you 
speculating?

> I don't see a justification
> why gfortran should go out of its way to help the user shoot himself
> in the foot.

Me neither. This is about the documentation - not about the compiler 
workings. I'm just telling you that you are making incorrect 
implications in your documentation. The behavior that you have right 
now *IS* valid f90 behavior, so I advise against saying or implying 
otherwise.

> I meant an option -std=f90, which would flag the new F95 features as
> illegal,

Yes. Though mostly only the compile-time ones (particularly the ones 
that the f90 standard requires diagnosis of). It isn't possible or 
expected to flag all the run time ones.

> not automatically deallocate non-saved allocatables etc.

No. See above.

>  I
> hope I have explained well enough why I think that the F95
> allocatables are a good thing

Agree. Again, I've never known a single person who thought otherwise. 
That includes the people who wrote it. It was more of an oversight and 
failure to come up with a good alternative. I don't think they thought 
this was actively a good idea as much as that they didn't have a good 
idea at the time (but later found one).

>  and that F90 allocatables should not be
> supported,

See above. You already do support "f90 allocatables". There is no such 
thing as an f90 allocatable that isn't also an f90 allocatable.

-- 
Richard Maine                |  Good judgment comes from experience;
Richard.Maine@nasa.gov       |  experience comes from bad judgment.
                             |        -- Mark Twain