Fortran - Scope of "implicit none" and interfaces

Author

Scope of "implicit none" and interfaces - rationale?

Harald Anlauf

2005-02-22, 4:01 pm

Hi experts,

can somebody briefly explain why it was chosen that interfaces are sort
of outside the scope of the program or module they are declared in?

An example:

program dummy
implicit none

interface
subroutine foo (i)
end subroutine foo
end interface

integer :: j = 1
call bar (j)

contains
subroutine bar (k)
integer :: k
call foo (k)
end subroutine bar
end program dummy

All compilers (except gfortran which exhibits a bug here and bails out)
swallow the above code without problems, unless forced by command line
options (like -u) or by an "implicit none" placed in the interface
definition.

Is there a fundamental reason why the scope of a useful declaration like
"implicit none" was not or could not be extended also to the interface?
(Fortunately it does apply to all contained functions and subroutines).

--
Cheers,
-ha

Jan Vorbrüggen

2005-02-22, 4:01 pm

I believe one of the reasons was that you would INCLUDE the interface
definition from a file provided by whoever wrote the routine you are
interfacing with, and that its author might be using a different con-
vention for implicit variable naming. In particular, this would apply
to "legacy code" written before IMPLICIT became part of the language.

Jan

Richard E Maine

2005-02-22, 4:01 pm

In article <380rfpF5g8cs2U1@individual.net>,
Jan Vorbrüggen <jvorbrueggen-not@mediasec.de> wrote:

> I believe one of the reasons was that you would INCLUDE the interface
> definition from a file provided by whoever wrote the routine you are
> interfacing with, and that its author might be using a different con-
> vention for implicit variable naming. In particular, this would apply
> to "legacy code" written before IMPLICIT became part of the language.

And note that it is not restricted to IMPLICIT (none or otherwise). Host
association doesn't go into interface bodies.

I personally happen to think that this was a mistake, which causes more
problems than the one it was meant to avoid. We now (in f2003) have a
language feature (import) whose sole purpose is to work around the
problems caused by this "mistake". But yes, Jan has accurately
described the cited reason for the behavior. In particular, I recall
mention of automatic interface body generators, which could just extract
the specification statements from a procedure and automatically write a
suitable interface body. The job of writing such interface body
generators is more complicated if you have to deal with host association
into the interface body.

--
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

James Giles

2005-02-22, 8:59 pm

Harald Anlauf wrote:
> Hi experts,
>
> can somebody briefly explain why it was chosen that interfaces are sort
> of outside the scope of the program or module they are declared in?

Suppose you have an external procedure that you are writing an
interface for. The information in the interface must match the actual
declarations of things inside the procedure itself. The procedure
itself is actually *prohibited* from USEing the module. Hence,
the procedure's declarations can't depend on anything in the
module. So, how can the interface for the procedure match
if it *does* rely on contents of the module?

I think the rule is bad simply because I think the procedure should
be permitted, even encouraged, to USE the module in which its
interface is described. The compiler could then check that the
interface matches the actual procedure's declarations.

None of this is directly applicable to your question which referrs to
IMPLICIT statements. These are not inherited by host association
or USE association in any context, not just interface blocks.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare

James Giles

2005-02-22, 8:59 pm

Richard E Maine wrote:
....
> And note that it is not restricted to IMPLICIT (none or otherwise). Host
> association doesn't go into interface bodies.
>
> I personally happen to think that this was a mistake, which causes more
> problems than the one it was meant to avoid. We now (in f2003) have a
> language feature (import) whose sole purpose is to work around the
> problems caused by this "mistake". [...]

This is a case of one mistake in the standard leading to a bigger mistake.
IMPORT has a valid meaning, but not in connection with the case of
this thread. The only valid use of IMPORT is with an interface that
describes a dummy argument or a procedure pointer target. In both
cases the actual procedure described by the interface can (and *should*)
be either a module procedure in the same module, or a procedure
elsewhere that USEs the module. In other words, the information
IMPORTed is also available within the procedure itself. If that's
not the case, the use of IMPORT is a subtle bug waiting to happen.
It will probably be the worst kind of bug: plausible wrong answers.
You may use the program for years without knowing there's a
problem at all.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare

Richard E Maine

2005-02-22, 8:59 pm

In article
<cuMSd.262506$w62.211742@bgtnsc05-news.ops.worldnet.att.net>,
"James Giles" <jamesgiles@worldnet.att.net> wrote:

> None of this is directly applicable to your question which referrs to
> IMPLICIT statements. These are not inherited by host association
> or USE association in any context, not just interface blocks.

Well... if I recall correctly, the standard doesn't call it host
association, but...

Implicit mappings *ARE* inherited from hosts (except into interface
bodies). They act just like host association, or close enough that I'd
have trouble telling the difference, so they might as well be called
that, even if that's not the standard's terminology.

In fact, inherited implicit mappings are the source of some of the
strangest things I know of in the language. It is possible to end up
being able to implicitly declare variables to be of a type that you
can't explicitly declare in the same scoping unit. I regard that as just
plain strange... and definitely in the category of things that one just
should not do, even though the standard allows it.

But I routinely take advantage of the "inheritance" of implicit none,
putting the implicit none in my module scope and then allowing that to
inherit into the contained module procedures et al.

--
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

James Giles

2005-02-22, 8:59 pm

Richard E Maine wrote:
> In article
> <cuMSd.262506$w62.211742@bgtnsc05-news.ops.worldnet.att.net>,
> "James Giles" <jamesgiles@worldnet.att.net> wrote:
>
>
> Well... if I recall correctly, the standard doesn't call it host
> association, but...
>
> Implicit mappings *ARE* inherited from hosts (except into interface
> bodies). They act just like host association, or close enough that I'd
> have trouble telling the difference, so they might as well be called
> that, even if that's not the standard's terminology.

Sorry, I misread something somewhere. I always put IMPLICIT NONE
in all my procedures regardless. One reason is that I always have to
compile them separately first anyway. If I don't, there's a danger of
acquiring something by host association that I don't want. There
being no way to refuse or restrict host association, it's far to easy
to get something from the host that I merely forgot to declare in the
procedure.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare

Sponsored Links