On Fri, Jul 28, 2017 at 1:32 AM, Malcolm Cohen <[log in to unmask]> wrote:
> Parameterised Derived Types.
>
My note on Fri, 28 Jul 2017 00:23:42 -0400 specifically included code
on parameterized derived types (PDTs) and it showed Intel Fortran
distinguishes between kinds of derived types in SAME_TYPE_AS intrinsic
inquiry consistent with how SELECT TYPE works. Readers, please, take
a moment to go through the code that is shown again below:
------ begin code --------
use, intrinsic :: iso_fortran_env, only : compiler_version
implicit none
type :: foo(k) ! <- Parameterized derived type
integer, kind :: k
end type
print *, "Compiler Version: ", compiler_version()
blk1: block
class(*), allocatable :: x
class(*), allocatable :: y
allocate( foo(k=1) :: x )
allocate( foo(k=1) :: y )
print *, "block 1"
print *, "same_type_as(foo(k=1) :: x, foo(k=1) :: y) = ",
same_type_as(x,y)
print *, "expected output is T", new_line("")
end block blk1
blk2: block
class(*), allocatable :: x
class(*), allocatable :: y
allocate( foo(k=1) :: x )
allocate( foo(k=2) :: y )
print *, "block 2"
print *, "same_type_as(foo(k=1) :: x, foo(k=2) :: y) = ",
same_type_as(x,y)
print *, "expected output is F", new_line("")
end block blk2
end
------ end code --------
Upon execution with Intel Fortran compiler,
------ begin output --------
Compiler Version:
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running
on Intel(R) 64, Version 18.0.0.083 Beta Build 20170510
block 1
same_type_as(foo(k=1) :: x, foo(k=1) :: y) = T
expected output is T
block 2
same_type_as(foo(k=1) :: x, foo(k=2) :: y) = F
expected output is F
------ end output --------
On Fri, Jul 28, 2017 at 1:32 AM, Malcolm Cohen <[log in to unmask]> wrote:
> SAME_TYPE_AS is fully defined to ignore kind here, i.e. it is not the same as SELECT TYPE.
>
Can other readers help me out here? When I look at the standard, all
I see is as being relevant is the sentence, "If neither A nor B has
extensible dynamic type, the result is processor dependent."
The standard text in no way informs me, as an ordinary Fortran user,
that this intrinsic "SAME_TYPE_AS is fully defined to ignore kind".
Now if one is paying very close attention, they might figure out the
text is silent on kinds but most coders will miss out on this.
So a processor such as Intel Fortran is standard-conforming to give F
as the result of the second inquiry in the above code and another
compiler that gives T for the same will also be conforming.
Now see this code:
------ begin code --------
use, intrinsic :: iso_fortran_env, only : compiler_version
implicit none
type :: foo(k)
integer, kind :: k
end type
class(*), allocatable :: x
class(*), allocatable :: y
print *, "Compiler Version: ", compiler_version()
allocate( foo(k=1) :: x )
allocate( foo(k=2) :: y )
select type ( x )
type is ( foo(k=1) )
print *, "select type: type of x is foo(k=1)"
type is ( foo(k=2) )
print *, "select type: type of x is foo(k=2)"
class default
print *, "select type: type of x is ??"
end select
select type ( y )
type is ( foo(k=1) )
print *, "select type: type of y is foo(k=1)"
type is ( foo(k=2) )
print *, "select type: type of y is foo(k=2)"
class default
print *, "select type: type of y is ??"
end select
end
------ end code --------
Upon execution with Intel Fortran,
------ begin output --------
Compiler Version:
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running
on Intel( R) 64, Version 18.0.0.083 Beta Build 20170510
select type: type of x is foo(k=1)
select type: type of y is foo(k=2)
------ end output --------
So coders will find Intel Fortran treat SAME_TYPE_AS consistently with
SELECT TYPE in this particular instance involving PDTs. But if coders
see a different response with some other compiler, they will be
stumped and this need not be so.
Can more folks, perhaps those on J3, try to explain to themselves and
to others here is it really such an adverse impact on semantics of one
intrinsic if it was to be refined? And also ask themselves what about
the semantics implications with "leave it alone" attitude on the
standard *overall* when ordinary users keep getting confused with an
inconsistency: "type" in SELECT TYPE means one thing which is
different from SAME_TYPE_AS.
Thanks,
Vipul
|