Query abt Allocatable Dummy argument in F2003

[Richard E Maine]

On Aug 8, 2005, at 1:14 AM, Sudesh Chandna, Noida wrote:

> Standard says " Interface must be explicit if dummy argument is 
> allocatable. I.e. either corresponding procedure/function is internal 
> or interface is given explicitly if its external". My question is: 
> Above constraint should be be taken care by user or compiler ?

First, please note that this is not a constraint as the term is used in 
Fortran. The term "constraint" is used with specific meaning in the 
Fortran standard. Use in its broader English meaning should therefore 
be avoided or confusions and errors will result. The constraints in 
f90/f95/f2003 are all explicitly annotated in the standard with the 
word "constraint"; in F2003 they also have constraint numbers for handy 
reference.  We usually use terms like "requirement" or "restriction" to 
refer to the other provisions of the standard - almost any word other 
than "constraint". The general English meaning of "constraint" fits, 
but it causes confusion when used that way in context of the Fortran 
standard. There are several other similar English words with specific 
technical meaning in the Fortran standard. The term "reference" comes 
to mind. The standard requires compilers to be able to diagnose 
constraints (item 3 in section 1.5 of f2003), but that specifically 
means the things annotated as constraints - not all the other material 
of the standard. See section 1.7.3 of f2003.

Second. The question of whether the compiler or the user is responsible 
for something is fundamental to many aspects of the standard. Often a 
requirement can have exactly opposite meanings depending on whether it 
is a requirement on the user or on the compiler. It is therefore 
absolutely critical to keep the first paragraph of 1.7 in mind. That 
apparently bland and innocuous-looking paragraph is critical to 
understanding the whole standard. Note in particular the part that says 
"Except where stated otherwise, such requirements and prohibitions 
apply to programs rather than processors."

The requirement that a processor be able to diagnose constraint 
violations states that it is a requirement on the processor. But the 
large majority of the requirements in the standard do not - that 
includes the one you are asking about.

Third, your "i.e." conclusion above is incorrect in several regards. 
Most notably, you seem to be classifying procedures as either internal 
or external. That is not a correct division; it neglects module and 
intrinsic procedures. The omission is notable in that I personally 
recommend the use of module procedures for code that uses constructs 
like this. The compiler has to be able to deal with all the cases, but 
I recommend that users use module procedures, in which case they won;t 
make errors like this. This is somewhat peripheral to your question, 
but it has to be completely understood to have any hope of working on 
implementation.

> Also kindly note that same constraint is there for pointer attribute. 
> "Interface must be explicit if dummy argument has pointer attribute". 
> (Section 12.3.1.1) But Gfortran doesn't generate any error message if 
> interface is not given explicitly.

First, it is not a constraint. See above.

Second, there is a reason that it isn't a constraint. It is not 
possible to diagnose this at compile time without throwing out separate 
compilation of external procedures. That is because it is valid to pass 
a pointer as an actual argument when the dummy is not a pointer. That 
has the effect of passing the target of the pointer and it does not 
require an explicit interface. The whole reason for requiring an 
explicit interface is that the compiler won't in general know what is 
intended unless there is an explicit interface to tell it.

> Is this a bug in Gfortran ?

No. Nor is it even a poor quality of implementation. This is about what 
would be expected from that particular error in most cases. Some 
compilers *MIGHT* happen to detect the problem in some cases - most 
notably if the call and the subroutine are in the same source file. But 
that is not at all something you can count on; it constitutes a 
compiler going "above and beyond the call of duty." Namely, it is 
certainly a nice feature for a compiler, but more a "luxury" than part 
of the basic expectations.

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