import statement and renamed type

[clabra]

Hi,

I'm trying to use the following type of "template" in fortran, but I have some question about the implementation.
The code compile and run without problem with the intel compiler, but if I try to use other compilers (sun,gfortran,g95), I have some compilation errors ( different errors for each compiler ):

------- print_coord.f90 -------
subroutine print_coord(coord)
real(8), dimension(3), intent(in) :: coord
print*,coord
end subroutine print_coord
-----------------------------------------
------- print_data_type.i90 -------
!module DATA_TYPE_mod
!use data_type_module, only: data_type => point_t
private

interface print_type_coord
subroutine print_coord(point)
import:: data_type
type(data_type), intent(in) :: point
end subroutine print_coord
end interface print_type_coord

public:: print_type_coord

!end module DATA_TYPE_mod
---------------------------------------------
------- test.f90 -------
module types
public
type point_t
real(8), dimension(3) :: coord
integer :: id
end type point_t
type sphere_t
real(8), dimension(3) :: coord
real(8) :: radius
integer :: id
end type sphere_t
end module types
!--
module point_mod
use types, only: data_type => point_t
include "print_data_type.i90"
end module point_mod
!--
module sphere_mod
use types, only: data_type => sphere_t
include "print_data_type.i90"
end module sphere_mod
!--
program test
use types
use point_mod, only: print_point_coord => print_type_coord
use sphere_mod, only: print_sphere_coord => print_type_coord

type(point_t) :: point
type(sphere_t) :: sphere

point = point_t( (/0.0,0.0,0.0/) , 1 )
sphere = sphere_t( (/1.0,1.0,1.0/), 0.5, 2 )

call print_point_coord(point)
call print_sphere_coord(sphere)

end program test
---------------------------------

I don't know if the fortran 2003 standard permit "import" a renamed type.
Maybe someone can help me with this, or with a better way of make "templates" in fortran.

thanks
 

[Steven_L_Intel1]

All the standard says is that IMPORT causes names that are visible in the host context to be visible in the interface body. Renamed entities are not special cases. This should work fine.

[clabra]

Thanks Steve!
An extra question about this is: if I have two public types with the same name (data_type), is it possible some kind of problem or conflict when the "import" statement is used??

[Steven_L_Intel1]

If you have two entities from different modules but with the same name visible in a scope, you can't use that name - period. If you want to use one of them, you'll have to rename the other or exclude it using ONLY. IMPORT doesn't change this - if you can use the name in the host scope, you can use it in the interface body with IMPORT. Conversely, if you can't use it in the host scope, IMPORT doesn't make the name usable.

So if you have something like this:

module a
type data_type
integer i
end type data_type
end module a

module b
type data_type
real r
end type data_type
end module b

program foo
use a
use b

at this point, data_type cannot be referenced - even if the type declarations were "the same", they are different declarations according to the language. You could do this:

use a, a_type => data_type
use b

now you have access to both definitions, though with different names.

[clabra]

Ok, I understand perfectly, but if you have a subroutine defined in the module a, the access persist for the type a_type ??

module a
type data_type
integer i
end type data_type
contains
subroutine foo1(data)
type(data_type), intent(in) :: data
print*,data
end subroutine foo1
end module a

program foo
use a, a_type => data_type
type(a_type) :: a_data
...
call foo1(a_data)
...

The rename can affect the access to some routine ?

[Steven_L_Intel1]

The renaming of data_type to a_data is only for the "program foo". It has no effect on the module or subroutine. The compiler knows they're really the same type. Does that answer your question?

[clabra]

Yes. many thanks!
I hope the other compilers enable this, for the portability problem. I believe is really useful this way of "templates" for not write different files with the same routines.

[Steven_L_Intel1]

IMPORT is a feature of the Fortran 2003 standard, so any compiler which implements IMPORT doesn't have a choice in how to do it. Similarly, the rules on renaming are from Fortran 90 so any difference in behavior is simply a compiler bug.

[Steven_L_Intel1]

It has come to my attention that I overlooked a problem with the code in the original post - the interface block for print_coord does not match the declarations in the actual routine itself. This is not allowed by the standard, but because print_coord is an external routine compilers may or may not notice the mismatch. (Intel Fortran will if you use generated argument checking.)

My earlier comments regarding the behavior of IMPORT stand - I did not mean to imply that deliberately mismatching argument types was standard-conforming.

[clabra]

I understand. But the main idea is make something like the "static_cast" (C++) of the routine arguments. As fortran use pointer arguments in the routines, then it is possible make it.
I'm not sure if this is not allowed by the standard or directly is not in the standard this possiblity.
The thing is find a way of use some kind of "template" style for the programing.
I ask the same in the SUN Compiler forum and the answer was equivalent. But the sun compiler generate a warning in the compilation of the files.

[Steven_L_Intel1]

Intel Fortran should also complain if you used the "-gen-interface -warn interface" options.

The Fortran standard, at present, does not allow for a deliberate type mismatch. The standard way to do this is through generic procedures, but this would require different procedures for each combination of type, kind and rank. You may be able to make it work if you don't mind violating the standard, but this is implementation-dependent.

There is a proposal being circulated around the Fortran committee for syntax that would selectively relax interface checking rules. Most compilers already implement this with implementation-dependent syntax (Intel's is !DEC$ ATTRIBUTES NO_ARG_CHECK), but there is disagreement among committee members as to what it should look like and what it should mean.