module interface

[mtrover]

I'm working with CVF 6.6B and ran across the following error.

module new

type mat_struc
real(kind=4):: M(3,3)
end type

interface mul
module procedure MulLeft, MulRight
end interface

contains

function MulLeft(A,B)
real(kind=4):: MulLeft(3,3), B(3,3)
type(mat_struc):: A
MulLeft = matmul(A%M,B)
end function

function MulRight(B,A)
real(kind=4):: MulRight(3,3), B(3,3)
type(mat_struc):: A
MulRight = matmul(B,A%M)
end function

end module

The interface statement argues that MulLeft and MulRight have the same type, and rank and cannot be used for a generic interface. Obviously, it is ignoring the type and order of the dummy arguments.

Is this error correct for Fortran, or is my code failing some condition?

MikeT

[Steven_L_Intel1]

Consider the following program:

type(mat_struct) :: X
real(4) :: Y(3,3), Z(3,3)

Z = Mul(A = X, B = Y)

Which one gets invoked?

The rules for generic disambiguation are complex, but are spelled out clearly in the documentation.

Steve

[mtrover]

Well, Steve, if it can't figure it out then it can't do non-commutative algebra. The point is, there is a difference in notation, and this notation does indicate a significant difference- MulLeft and MulRight most certainly return different values. If there is no difference between f(a,b) and f(b,a) where a and b are different types, why would the compiler flag an error if you got the order wrong? Since a function is defined by its interface than f(a,b) and g(b,a) where a and b are different types are most certainly different functions because they have a different interface. For instance, you couldn't pass g as the formal argument for the interface of f as a dummy argument.

[Steven_L_Intel1]

The compiler complains that the generic is ambiguous because it is - Fortran allows you to use keywords to name the arguments, and since both procedures have an A of the same type and both have a B of the same type, they're potentially ambiguous.

You can fix this by giving the arguments different names in the different procedures. That way there can't be an ambiguity by name.

Steve

[mtrover]

Thanks, Steve. It took a while to orient my thinking to the problem. It finally filtered through.

My own impression, giving a name to a place-type connection is certainly dangerous, but in this case easy to overcome.

Thanks again.

MikeT

[Steven_L_Intel1]

Argument keywords can be very powerful, especially when you have optional arguments. While they may get in the way of generics, for non-generic procedures, they can help clarify the code. I've seen too many routine calls passing 20+ arguments, and counting them can be tedious if you're trying to identify a particular one.

Steve