should this give a compile error?

[andrew_4619]

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.

[jimdempseyatthecove]

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

[andrew_4619]

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?

[Steven_L_Intel1]

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

[IanH]

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.

[andrew_4619]

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.  

[IanH]

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.

[Steven_L_Intel1]

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.

[andrew_4619]

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!