Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Valued Contributor III
19 Views

should this give a compile error?

module santa
    implicit none
    interface
        module subroutine rudolph(nose)
        end subroutine rudolph
    end interface
end module santa

This compiles just fine by default options. If you set for warnings about undeclared variables you do get a warning. To my thinking (which may be wrong) the inheritance from the parent module should mean that rudolph's nose should have an explicit type in Santa's module.

0 Kudos
8 Replies
Highlighted
19 Views

If nose were declared as a variable within the parent module the nose specified as the dummy argument should be a locally (to santa) defined dummy that hides the outer scoped nose (any may be of different type).

Jim Dempsey

0 Kudos
Highlighted
Valued Contributor III
19 Views

It is a submodule Jim so that IMPLICIT NONE will automatically apply to the implimentation of santa why would it not then apply to the interface to santa given the two must match each other exactly. Also, with submodules you do not need IMPORT in the interface as there is automatic inheritance into the interface from the parent module. Why would that inheritance not include IMPLICIT typing?

 

0 Kudos
Highlighted
19 Views

The compiler is correct - IMPLICIT NONE is not inherited by an interface block, since an interface block is not in the scoping unit. Indeed, the standard gives this as an example:

The following are examples of the use of IMPLICIT statements:
MODULE EXAMPLE_MODULE
IMPLICIT NONE
...
INTERFACE
FUNCTION FUN (I) ! Not all data entities need to
INTEGER FUN ! be declared explicitly
END FUNCTION FUN
END INTERFACE

CONTAINS
FUNCTION JFUN (J) ! All data entities need to
INTEGER JFUN, J ! be declared explicitly.
...
END FUNCTION JFUN
END MODULE EXAMPLE_MODULE

0 Kudos
Highlighted
Black Belt
19 Views

rudolph will typically be defined in a submodule - if so that submodule is a separate program unit that has an independent implicit mapping from the ancestor module.  The implicit mapping in the interface body being the default, in the absence of a specification in the interface body to the contrary, is consistent with this - as the implicit mapping in the submodule will be the default in the absence of a specification to the contrary.

0 Kudos
Highlighted
Valued Contributor III
19 Views

Thanks for the clarification Steve if that is how it is then fine. But an interface to a submodule function does not have that same rules as an 'ordinary' function, for example.

module santa
    implicit none
    integer, parameter :: DP =8
    interface
        module subroutine rudolph(nose)
            real(DP) :: nose
        end subroutine rudolph
    end interface
end module santa

The above is OK but if I remove the "module" from "module subroutine" is not OK it would then need "IMPORT" to bring DP in to the interface.  

0 Kudos
Highlighted
Black Belt
19 Views

A submodule is a separate program unit from a module.  It has its own implicit type mapping, independent of the ancestor module.  The rules for the implicit type mapping in interface bodies are consistent with this.

A submodule can access entities from its ancestor module through host association.  The rules for host association of entities into an interface body for a separate module procedure (MODULE keyord) are also consistent with this.

0 Kudos
Highlighted
19 Views

The rules for importing definitions from the host of an interface block are weird because Fortran 90 got it wrong, in some ways. The notion was that an interface block is a "window" into the external procedure, and you'd need to declare or USE in the external procedure to match the declaration. This is what IMPORT was intended to address. In the context of submodules, the submodule DOES inherit all of the symbols from the host so it makes sense to have the interface do the same.

0 Kudos
Highlighted
Valued Contributor III
19 Views

Steve Lionel (Intel) wrote:
 In the context of submodules, the submodule DOES inherit all of the symbols from the host so it makes sense to have the interface do the same.

I guess this very simple  query does illustrate that writing and updating the standard is a very difficult job. To move forward whilst seeing all the ramifications and consequences of all the historical 'baggage' of the language requires a lot of thinking!

As discussed, this case doesn't cause any real problem, if you do not have the warning for declarations on you may still get an error when you later compile the submodule that implements the interface as a result, if there is a mismatch. It just seems a little wrong that if you do get this error the "real" error is in a different source file!

When submodules were considered as a new feature I guess it could have been a option  to insist that the interfaces were always fully explicit. This sort of makes sense to me as implicit  types are really an obsolescent feature to be discouraged in new code IMO. On the other maybe this would have some unhappy side effects......

Anyway item closed as far as I am concerned!

 

 

0 Kudos