Re: Scope of implicit none

On 22 sep, 09:33, nos...@xxxxxxxxxxxxx (Richard Maine) wrote:
Arjen Markus <arjen.mar...@xxxxxxxxxx> wrote:
I have a question about the scope (if that is the proper name) of an
IMPLICIT NONE.
The following program causes an error message with gfortran, but not
with g95 or ifort:

[example elided]

The error message with gfortran is that the function f has no IMPLICIT
type. That seems to indicate that the IMPLICIT NONE statement is
active in for the interface block too. As the other two compilers do not
complain about it, I assume that they do not let this IMPLICIT NONE
statement make itself felt inside an interface block.

Which is the right interpretation? (If there is a right
interpretation)

There is no host association into an interface body. (Strictly speaking,
it is the interface body that has a separate scope - the interface block
does not, though for a simple case like this, the distinction isn't
apparent).

This is a special case, and one that has been the subject of much
controversy. The f90 standard explicitly said that host association did
apply to interface bodies, and gave examples of it. However, an early
"interpretation" declared this to be an error and changed it. I never
did quite figure out how that was an "interpretation" or an "error"
insomuch as it was internally consistent. It looked to me just like some
people just changed their mind about how it should be. I didn't think
that kind of thing was supposed to be allowed in interpretations, but...
well... that's what happened. Thus the f90 standard, as officially
interpreted and amended by the corrigenda, says that the implicit none
statement doesn't go into the interface body. F95 incorporated the f90
corrigenda and thus says the same.

By the time f2003 was being developed, it had become apparent that the
lack of host association into interface bodies was causing significant
problems. It seemed to me like people were having what I might call
third thoughts... that maybe the f90 interp wasn't such a good idea
after all. But by then, it was about a decade too late to undo the
interp. So it was left in place, but the IMPORT statement was added. In
my view (well, this all is my view) the IMPORT statement was nothing but
a kludge around the inconsistency introduced by the f90 interp.

I can, by the way, see plenty of arguments on both sides (as well as
some intermediate points) on the issues of how best to handle host
association. What I don't buy is handling it differently for interface
bodies than for everything else. But that's the way it is.

That was the long answer. The short answer is that it looks like
gfortran has it wrong (based on your report - I haven't checked myself).

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

Because of the necessity to use extra USE statements in an
interface block, I thought it would work the same way with
IMPLICIT NONE - that seems in agreement with your explanation
(not that I like the fact that host association does not
extend to these interface blocks - it requires rather
clumsy extra modules sometimes, for no other purpose than
defining a derived type that can then be accessed in the
interface block).

I will report this to the gfortran people.

Regards,

Arjen
.

Relevant Pages

  • Re: Interface declarations
    ... IMPLICIT NONE ... Note that this is different from the examples that have been discussed earlier -- it says "INTERFACE flux_godunov" rather than just "INTERFACE". ... Thus, this is a completely different thing: It is an interface block that defines a generic, and thus it is completely legal. ... But, as I say, it's quite legal, and there are valid uses and times when it wouldn't be redundant. ...
    (comp.lang.fortran)
  • Re: Procedures as arguments - set dummy arguments
    ... implicit none ... lpCurrentDirectory, lpStartupInfo, lpProcessInformation & ... end interface ... public GetLastError ...
    (comp.lang.fortran)
  • Re: Fortran templates
    ... end module mykinds ... implicit real ... end interface initr1_int ... Maybe that's due to an old version of ifort: allowing intrinsics ...
    (comp.lang.fortran)
  • Re: mean function (intrinsic) in Fortran 95
    ... interface block to create a generic averagefunction that resolves the ... elemental subroutine x_int_assign ... end module mykinds ... implicit real ...
    (comp.lang.fortran)
  • Re: intent(in)
    ... something like explicit interface is one of those interface ... blocks and an implicit interface is what you get by using a module ... >> Standardese leaks into the world of common usage. ...
    (comp.lang.fortran)