Polymorphism in fortran - class

I have a code similar to:
Module C_sys
use class_A
implicit none
Private
Type, public :: C_sys_type
private
logical :: Ao_set = .false.
type(A) :: Ao
Contains
Private
Procedure, public :: get_Ao
Procedure, public :: set_Ao
End Type C_sys_type
interface C_sys_type
Procedure C_sys_type_constructor
end interface C_sys_type
Contains
type(C_sys_type) elemental function C_sys_type_constructor(Ao) result(C_sys)
type(A), intent(in), optional :: Ao
C_sys % Ao = Ao
C_sys % Ao_set = .true.
end function C_sys_type_constructor
type(A) elemental function get_Ao
class(C_sys_type), intent(in) :: this
get_Ao = this % Ao
end function get_Ao
subroutine set_Ao(this, Ao)
class(C_sys_type), intent(inout) :: this
type(Ao), intent(in) :: Ao
this % Ao = Ao
this % Ao_set = .true.
end subroutine set_Ao
End Module C_sys
I am not sure where in the subroutine set_Ao , type(Ao), intent(in) :: Ao should be left like this or instead to have class(Ao), intent(in) :: Ao. I know that class(Ao) is making the variable polymorphic and accessing the data type of A. But I don't know when it has to be used one or the other.
Thanks.

If you want to be able to bind a function/subroutine to a derived type (and for that routine to be able to access/modify the members of an instance of that type, which is the usual use-case; referred to as "PASSing" a variable), you need to meet the following conditions:
The TYPE definition must contain an appropriate PROCEDURE line (either with PASS explicitly stated, or there by-default whenever NOPASS is not specified).
The function/subroutine have at least one dummy argument of the TYPE in question, which must be declared in the argument list with CLASS (subject to all the restrictions that entails).
The reason it needs CLASS for this is that some other TYPE might "extend" your TYPE, which would mean it inherits its members - this can only work if the member routines are data-polymorphic.
I've attempted to modify your provided code sample into something representative of what I think you actually meant, but which actually compiles, to hopefully demonstrate correct usage.
module c_sys
implicit none
private
type, public :: a
integer :: i
end type
type, public :: c_sys_type
private
logical :: ao_set = .false.
type(a) :: ao
contains
private
procedure, public :: get_ao
procedure, public :: set_ao
end type c_sys_type
interface c_sys_type
procedure c_sys_type_constructor
end interface c_sys_type
contains
type(c_sys_type) elemental function c_sys_type_constructor(ao) result(c_sys)
type(a), intent(in), optional :: ao
c_sys % ao = ao
c_sys % ao_set = .true.
end function c_sys_type_constructor
type(a) elemental function get_ao(this)
class(c_sys_type), intent(in) :: this
get_ao = this % ao
end function get_ao
subroutine set_ao(this, ao)
class(c_sys_type), intent(inout) :: this
type(a), intent(in) :: ao
this % ao = ao
this % ao_set = .true.
end subroutine set_ao
end module c_sys
I assume your TYPE A and TYPE AO were defined in the CLASS_A module you haven't provided. I've declared a dummy type in my version.
Things can get more complex if you want to make use of NOPASS etc., but for "normal" usage I hope this answers your question.

Related

In fortran, why interface has a name? what does it do when you call the interface? [duplicate]

I'm trying to understand the difference between abstract interfaces and "normal" interfaces. What makes an interface abstract? When is each one necessary?
Suppose the examples below
module abstract_type_mod
implicit none
type, abstract :: abstract_t
contains
procedure(abstract_foo), pass, deferred :: Foo
end type
interface
subroutine abstract_foo ( this, a, b )
import :: abstract_t
implicit none
class(abstract_t), intent(in) :: this
real, intent(in) :: a
real, intent(out) :: b
end subroutine
end interface
end module
module concrete_type_mod
use abstract_type_mod
implicit none
type, extends ( abstract_t ) :: concrete_t
contains
procedure, pass :: Foo
end type
contains
subroutine Foo ( this, a, b )
implicit none
class(concrete_t), intent(in) :: this
real, intent(in) :: a
real, intent(out) :: b
b = 2 * a
end subroutine
end module
module ifaces_mod
implicit none
interface
subroutine foo_sub ( a, b )
implicit none
real, intent(in) :: a
real, intent(out) :: b
end subroutine
end interface
end module
module subs_mod
implicit none
contains
pure subroutine module_foo ( a, b )
implicit none
real, intent(in) :: a
real, intent(out) :: b
b = 2 * a
end subroutine
end module
program test
use ifaces_mod
use subs_mod
use concrete_type_mod
implicit none
type(concrete_t) :: concrete
procedure(foo_sub) :: external_sub
procedure(foo_sub), pointer :: foo_ptr
real :: b
foo_ptr => external_sub
call foo_ptr ( 0.0, b )
print*, b
foo_ptr => module_foo
call foo_ptr ( 1.0, b )
print*, b
call concrete%Foo ( 1.0, b )
print*, b
end program
pure subroutine external_sub ( a, b )
implicit none
real, intent(in) :: a
real, intent(out) :: b
b = a + 5
end subroutine
The output is
5.000000
2.000000
2.000000
I haven't used abstract interfaces here. At least I think I havent? I've been doing this for a while and I've never used the abstract "qualifier" on interfaces. It seems that I haven't found a case where using abstract interfaces is required.
Could someone enlighten me here?
PS: Compiler Intel Visual Fortran Composer XE 2013 SP1 Update 3.
Edit:
Quoting Metcalf, Reid and Cohen in Modern Fortran Explained:
In Fortran 95, to declare a dummy or external procedure with an
explicit interface, one needs to use an interface block. This is fine
for a single procedure, but is somewhat verbose for declaring several
procedures that have the same interface (apart from the procedure
names). Furthermore, in Fortran 2003, there are several situations
where this becomes impossible (procedure pointer components or
abstract-type bound procedures).
So, is my compiler in error for accepting the code below and also the one with abstract type above?
module ifaces_mod
implicit none
interface
subroutine foo_sub ( a, b )
implicit none
real, intent(in) :: a
real, intent(out) :: b
end subroutine
end interface
end module
module my_type_mod
use ifaces_mod
implicit none
type my_type_t
procedure(foo_sub), nopass, pointer :: Foo => null()
end type
end module
In both cases, I'd say that I actually have declared abstract interfaces without using the abstract keyword. I think my confusion has roots on the fact that the compiler is accepting code like this.
The "normal" interfaces — known by the standard as specific interface blocks (as you use in the title of the question) — are just normal interface blocks for some procedure. Therefore:
interface
subroutine foo_sub
end subroutine
end interface
means that there exists an actual (external) subroutine named foo_sub and it conforms to the specified interface.
An abstract interface
abstract interface
subroutine foo_sub_abs
end subroutine
end interface
just specifies how some procedure may look like, but the name is the name of the interface, not of any actual procedure. It can be used for a procedure pointers
procedure(foo_sub_abs), pointer :: p
or for a dummy arguments
subroutine bar(f)
procedure(foo_sub_abs) :: f
and it means that the actual procedure to which p will point or which is passed as f conforms to the abstract interface.
Note that you are allowed to use some existing procedure instead of an abstract interface in both two former examples. It just needs to have explicit interface available in the scope (typically it is in the same module, or in a module which is used).
As far as I know (but see #IanH's comment below) the compiler is allowed to refuse your code:
interface
subroutine abstract_foo ( this, a, b )
import :: abstract_t
implicit none
class(abstract_t), intent(in) :: this
real, intent(in) :: a
real, intent(out) :: b
end subroutine
end interface
because there exists no actual procedure named abstract_foo. Some compilers do not diagnose this, but they could.
Quite unrelated are generic interfaces. You can recognize them, because there is a name of a generic procedure after the word interface
interface generic_sub
procedure sub1
subroutine sub2(...)
end subroutine
end interface
Here sub1 and sub2 both exist, sub1 is already known and has already explicit interface available, sub2 is external and looks as the interface specifies, and both are specific procedure of the generic generic_sub. This is quite a different usage.
You then call
call generic_sub(...)
and according to the arguments you pass, the compiler chooses which specific procedure is called, if it is sub1, or sub2.
I would stress that these can be split into sparate interface blocks with the same name declared at different locations. You can add a specific procedure into an existing generic procedure this way.

Type that is a real OR an array of reals

I have the following problem:
I have a module containing some fortran function, which takes 2 (mathematical) functions as its input. The way I do this at the moment is by defining an interface for the input functions. My module looks like this:
module myModule
implicit none
save
abstract interface
subroutine functype1(x,f)
import dp
real(kind=dp), dimension(:),intent(in) :: x
real(kind=dp), dimension(:),intent(out):: f
end subroutine
subroutine functype2(x,M)
import dp
real(kind=dp), dimension(:),intent(in) :: x
real(kind=dp), dimension(:,:),intent(out):: M
end subroutine
end interface
contains
function taylorExpansion(func,funcdiff)
procedure(functype1) :: func ! The mathematical function f
procedure(functype2) :: funcdiff ! The function evaluating the derivative/gradient of f
! ...
! (further implementation)
! ...
end function
The problem is now that I want functype1 to be kind of general: sometimes the input is just a real, sometimes it's an array of reals. Is it possible to do this smoothly?
(At the moment I'm forced to pass an array of size 1 to func1 instead of a real, which is quite clumsy)
Another way to formulate this is: is it possible to make a type which is a real OR an array of reals? This way both calls would be possible:
program testprog
use myModule
implicit none
save
call taylorExpansion(xsquared,xdiff) ! functype1 can accept reals
call taylorExpansion(vectornorm,vectornormdiff) ! functype1 can also accept vectors
contains
subroutine xsquared(x,fx)
real(kind=dp) :: x
real(kind=dp) :: fx
fx = x**2
end subroutine
subroutine twox(x,fx)
real(kind=dp) :: x
real(kind=dp) :: fx
fx = 2*x
end subroutine
subroutine vectornorm(x,fx)
real(kind=dp), dimension(:) :: x
real(kind=dp) :: fx=0.0
integer i
do i = 1,size(x)
fx = fx + x(i)**2
end do
end subroutine
subroutine vectornormdiff(x,fx)
real(kind=dp), dimension(:) :: x
real(kind=dp), dimension(:) :: fx
integer i
do = 1,size(x)
fx(i) = 2*x(i)
end do
end subroutine
end program

Breaking up a Module into Multiple Files in Fortran

I'm attempting to add conversion functions to between different derived types. I'm
wanting them to be functions of the first derived type that returns the other derived type. This is no problem as long as they are in the same file and module. But I'd really like them to be able to be separated into multiple files since otherwise it would be a very large file. I can't figure out how to do this because of dependencies, and the lack of namespace in Fortran.
Is there a way to do this?
Here is an example of what I'd like to be dividing into two files (one for each derived type).
Module ConversionStuff
implicit none
type A_T
real :: a, b, c
contains
procedure :: toX => a_toX
end type A_T
type X_T
real :: x, y, z
contains
procedure :: toA => x_toA
end type X_T
contains
function a_toX(this) result(x)
class(A_T), intent(inout) :: this
type(X_T) :: x
x%x = this%a * 2
x%y = this%b * 2
x%z = this%c * 2
end function a_toX
function x_toA(this) result(a)
class(X_T), intent(inout) :: this
type(A_T) :: a
a%a = this%x * 0.5
a%b = this%y * 0.5
a%c = this%z * 0.5
end function x_toA
End Module ConversionStuff
I do apologize if there is a typo. I don't have an easy way to compile Fortran on this computer.
Within the current language this is easily enough dealt with through submodules - both type definitions go into the ancestor module along with the interfaces for the "shared" separate module procedures, procedure definitions are then split between submodules as it suits.
MODULE ConversionStuff
IMPLICIT NONE
TYPE :: A_T
REAL :: a, b, c
CONTAINS
PROCEDURE :: toX => a_toX
END TYPE A_T
TYPE :: X_T
REAL :: x, y, z
CONTAINS
PROCEDURE :: toA => x_toA
END TYPE x, y, z
INTERFACE
MODULE FUNCTION a_toX(this) RESULT(x)
IMPLICIT NONE
CLASS(A_T), INTENT(IN) :: this
TYPE(X_T) :: x
END FUNCTION a_toX
MODULE FUNCTION x_toA(this) RESULT(a)
IMPLICIT NONE
CLASS(X_T), INTENT(IN) :: this
TYPE(A_T) :: a
END FUNCTION x_toA
END INTERFACE
END MODULE ConversionStuff
SUBMODULE (ConversionStuff) Procedures_for_X
IMPLICIT NONE
CONTAINS
MODULE PROCEDURE a_toX
x%x = this%a * 2
x%y = this%b * 2
x%z = this%c * 2
END PROCEDURE a_toX
END SUBMODULE Procedures_for_X
...
Prior to Fortran 2008, you can sometimes use an alternative approach that emulates the above - the implementation of the procedures goes in a separately compiled set of external procedures that use the module. Care needs to be taken that the external procedures do not have visibility of their own interface.
MODULE ConversionStuff
IMPLICIT NONE
TYPE :: A_T
REAL :: a, b, c
CONTAINS
PROCEDURE :: toX => a_toX
END TYPE A_T
TYPE :: X_T
REAL :: x, y, z
CONTAINS
PROCEDURE :: toA => x_toA
END TYPE x, y, z
INTERFACE
FUNCTION a_toX(this) RESULT(x)
IMPORT :: A_T
IMPORT :: X_T
IMPLICIT NONE
CLASS(A_T), INTENT(IN) :: this
TYPE(X_T) :: x
END FUNCTION a_toX
FUNCTION x_toA(this) RESULT(a)
IMPORT :: A_T
IMPORT :: X_T
IMPLICIT NONE
CLASS(X_T), INTENT(IN) :: this
TYPE(A_T) :: a
END FUNCTION x_toA
END INTERFACE
PRIVATE :: a_toX
PRIVATE :: x_toA
END MODULE ConversionStuff
FUNCTION A_toX(this) RESULT(x)
USE ConversionStuff
IMPLICIT NONE
CLASS(A_T), INTENT(IN) :: this
TYPE(X_T) :: x
...etc...
END FUNCTION A_toX
There are limitations for the use of Fortran's accessibility attributes (PUBLIC and PRIVATE) for this second approach.
Note that the problem has nothing to do with namespaces, as the concept is typically defined.
After working on other things and coming back to this almost 2 months later. I found something I think is far more simple and elegant for this specific usage. I'm going to leave the previously accepted answer because it definitely answers the question, but this is an alternative method.
It uses the include keyword. I didn't understand until now that it doesn't compile included file until it is compiling the including file. Maybe there is something I don't understand, but for this situation where I only want to split into multiple files so that my single file isn't enormous, I think this method is worth the trade off in what I lose for it not being a module. If there is something I'm missing please let me know.
My solution is below.
Module ConversionStuff
implicit none
type A_T
real :: a, b, c
contains
procedure :: toX => a_toX
end type A_T
type X_T
real :: x, y, z
contains
procedure :: toA => x_toA
end type X_T
contains
include "A.f90"
include "X.f90"
End Module ConversionStuff
A.f90
function a_toX(this) result(x)
class(A_T), intent(inout) :: this
type(X_T) :: x
x%x = this%a * 2
x%y = this%b * 2
x%z = this%c * 2
end function a_toX
X.f90
function x_toA(this) result(a)
class(X_T), intent(inout) :: this
type(A_T) :: a
a%a = this%x * 0.5
a%b = this%y * 0.5
a%c = this%z * 0.5
end function x_toA

Difference between Fortran's "abstract" and "normal" interfaces

I'm trying to understand the difference between abstract interfaces and "normal" interfaces. What makes an interface abstract? When is each one necessary?
Suppose the examples below
module abstract_type_mod
implicit none
type, abstract :: abstract_t
contains
procedure(abstract_foo), pass, deferred :: Foo
end type
interface
subroutine abstract_foo ( this, a, b )
import :: abstract_t
implicit none
class(abstract_t), intent(in) :: this
real, intent(in) :: a
real, intent(out) :: b
end subroutine
end interface
end module
module concrete_type_mod
use abstract_type_mod
implicit none
type, extends ( abstract_t ) :: concrete_t
contains
procedure, pass :: Foo
end type
contains
subroutine Foo ( this, a, b )
implicit none
class(concrete_t), intent(in) :: this
real, intent(in) :: a
real, intent(out) :: b
b = 2 * a
end subroutine
end module
module ifaces_mod
implicit none
interface
subroutine foo_sub ( a, b )
implicit none
real, intent(in) :: a
real, intent(out) :: b
end subroutine
end interface
end module
module subs_mod
implicit none
contains
pure subroutine module_foo ( a, b )
implicit none
real, intent(in) :: a
real, intent(out) :: b
b = 2 * a
end subroutine
end module
program test
use ifaces_mod
use subs_mod
use concrete_type_mod
implicit none
type(concrete_t) :: concrete
procedure(foo_sub) :: external_sub
procedure(foo_sub), pointer :: foo_ptr
real :: b
foo_ptr => external_sub
call foo_ptr ( 0.0, b )
print*, b
foo_ptr => module_foo
call foo_ptr ( 1.0, b )
print*, b
call concrete%Foo ( 1.0, b )
print*, b
end program
pure subroutine external_sub ( a, b )
implicit none
real, intent(in) :: a
real, intent(out) :: b
b = a + 5
end subroutine
The output is
5.000000
2.000000
2.000000
I haven't used abstract interfaces here. At least I think I havent? I've been doing this for a while and I've never used the abstract "qualifier" on interfaces. It seems that I haven't found a case where using abstract interfaces is required.
Could someone enlighten me here?
PS: Compiler Intel Visual Fortran Composer XE 2013 SP1 Update 3.
Edit:
Quoting Metcalf, Reid and Cohen in Modern Fortran Explained:
In Fortran 95, to declare a dummy or external procedure with an
explicit interface, one needs to use an interface block. This is fine
for a single procedure, but is somewhat verbose for declaring several
procedures that have the same interface (apart from the procedure
names). Furthermore, in Fortran 2003, there are several situations
where this becomes impossible (procedure pointer components or
abstract-type bound procedures).
So, is my compiler in error for accepting the code below and also the one with abstract type above?
module ifaces_mod
implicit none
interface
subroutine foo_sub ( a, b )
implicit none
real, intent(in) :: a
real, intent(out) :: b
end subroutine
end interface
end module
module my_type_mod
use ifaces_mod
implicit none
type my_type_t
procedure(foo_sub), nopass, pointer :: Foo => null()
end type
end module
In both cases, I'd say that I actually have declared abstract interfaces without using the abstract keyword. I think my confusion has roots on the fact that the compiler is accepting code like this.
The "normal" interfaces — known by the standard as specific interface blocks (as you use in the title of the question) — are just normal interface blocks for some procedure. Therefore:
interface
subroutine foo_sub
end subroutine
end interface
means that there exists an actual (external) subroutine named foo_sub and it conforms to the specified interface.
An abstract interface
abstract interface
subroutine foo_sub_abs
end subroutine
end interface
just specifies how some procedure may look like, but the name is the name of the interface, not of any actual procedure. It can be used for a procedure pointers
procedure(foo_sub_abs), pointer :: p
or for a dummy arguments
subroutine bar(f)
procedure(foo_sub_abs) :: f
and it means that the actual procedure to which p will point or which is passed as f conforms to the abstract interface.
Note that you are allowed to use some existing procedure instead of an abstract interface in both two former examples. It just needs to have explicit interface available in the scope (typically it is in the same module, or in a module which is used).
As far as I know (but see #IanH's comment below) the compiler is allowed to refuse your code:
interface
subroutine abstract_foo ( this, a, b )
import :: abstract_t
implicit none
class(abstract_t), intent(in) :: this
real, intent(in) :: a
real, intent(out) :: b
end subroutine
end interface
because there exists no actual procedure named abstract_foo. Some compilers do not diagnose this, but they could.
Quite unrelated are generic interfaces. You can recognize them, because there is a name of a generic procedure after the word interface
interface generic_sub
procedure sub1
subroutine sub2(...)
end subroutine
end interface
Here sub1 and sub2 both exist, sub1 is already known and has already explicit interface available, sub2 is external and looks as the interface specifies, and both are specific procedure of the generic generic_sub. This is quite a different usage.
You then call
call generic_sub(...)
and according to the arguments you pass, the compiler chooses which specific procedure is called, if it is sub1, or sub2.
I would stress that these can be split into sparate interface blocks with the same name declared at different locations. You can add a specific procedure into an existing generic procedure this way.

interfaced type-bound procedures in Fortran

I am trying to define an interfaced procedure as a type-bound procedure in a Fortran type definition, but it seems it doesn't work as one would expect. Consider the following module:
module example_module
implicit none
private
interface add_them
module procedure add_them_integer,add_them_real
end interface add_them
type, public :: foo
integer, private :: a=1,b=2
real, private :: c=4.,d=5.
contains
procedure, public :: add => add_them
end type foo
contains
subroutine add_them_integer(self,x)
class(foo), intent(in) :: self
integer, intent(in) :: x
print *,self%a+self%b+x
end subroutine add_them_integer
subroutine add_them_real(self,x)
class(foo), intent(in) :: self
real, intent(in) :: x
print *,self%c+self%d+x
end subroutine add_them_real
end module example_module
and the corresponding program that uses the module:
program example
use example_module
implicit none
type(foo) :: foofoo
call foofoo%add(1)
call foofoo%add(2.)
end program example
I would expect this to compile and results should be 4 and 11. However, gfortran reports the following error:
procedure, public :: add => add_them
1
Error: 'add_them' must be a module procedure or an external procedure with an explicit interface at (1)
A workaround is to use generic type-bound procedure instead of an interfaced one, so that the module is as follows:
module example_module
implicit none
private
type, public :: foo
integer, private :: a=1,b=2
real, private :: c=4.,d=5.
contains
generic, public :: add => add_them_integer,add_them_real
procedure, private :: add_them_integer,add_them_real
end type foo
contains
subroutine add_them_integer(self,x)
class(foo), intent(in) :: self
integer, intent(in) :: x
print *,self%a+self%b+x
end subroutine add_them_integer
subroutine add_them_real(self,x)
class(foo), intent(in) :: self
real, intent(in) :: x
print *,self%c+self%d+x
end subroutine add_them_real
end module example_module
This works as expected. However, I cannot use a generic procedure. The above is just a simplified example to demonstrate the problem, but in my actual code 'add_them' cannot be a generic procedure because 'foo' is actually a derived-type and 'add_them' overrides a procedure defined in the parent type; gfortran (at least) does not allow generic procedures overriding base procedures. To bypass this restriction, I thought I should use an interface instead, but as you can see in the above example, although 'add_them' is defined correctly, compiler complains that "'add_them' must be a module procedure or an external procedure with an explicit interface".
Any help would be appreciated; thanks in advance.
The gfortran error for your first section of code is correct. The way to do generic bindings is as per your "works as expected" section of code.
If a parent type has a specific binding with a certain name, then you cannot reuse that name in extensions, other than to override the specific binding.
If you want add (note the name add_them doesn't appear in your second case) to be a generic binding in extensions, then make it a generic binding in the parent.