On Mon, Jul 31, 2017 at 1:36 PM, Steve Lionel wrote:
> I submitted a bug report (02976306) on this to Intel. I agree with Malcolm
> that ifort's behavior does not match the standard. But I also agree with
> Vipul that it would be helpful if there was a note (either in SAME_TYPE_AS,
> or maybe under Dynamic Type) indicating that type parameters are not
> considered where the standard references only "dynamic type".
Thanks much, Steve, for your follow-up with Intel as well as your comments.
A clarifying note in the standard, as suggested by Steve, will be
useful, if nothing else is done on this. Such a note likely would
have helped Intel developers "get it right the first time" and
possibly assist other implementations too.
However, I suggest the matter be considered and at least discussed a
bit further for a possible enhancement i.e., why not revise the very
definition in the standard for "dynamic type" to also include type
parameters?
Instead of immediately dismissing it as "no, that is not possible",
can readers consider a thought exercise where, say, the "dynamic type"
is defined as "type and type parameters of a data entity at a
particular point during execution of a program"? Will this not help
realize some simplification to language semantics as well as bring
some additional value for coders? The latter because it will then be
aligned, IMO, with coders' intuition on what constitutes a dynamic
type in relevant situations such as deallocation and finalization,
procedure binding, etc.
If I read through N2123 committee draft toward Fortran 2015 and
consider where "dynamic type" is referenced, I find it will either
simplify the standard text and consequently the language semantics or
it will have no impact. For the sake of some brevity (!!), I list
below the first 16 instances where "dynamic type" is mentioned in
N2123 where numbered phrases 1), 2), 3), etc. for each occurrence of
"dynamic type" in N2123 are shown along with my observations on what
such a change would yield.
---------------------------------------------
1) No change needed
3.110
polymorphic
(data entity) able to be of differing dynamic types during program
execution (7.3.2.3)
2) Include type parameters
3.147.4
dynamic type
type and type parameters of a data entity at a particular point
during execution of a program (7.3.2.3, 10.1.9)
3) No change needed
3.152
unlimited polymorphic
able to have any dynamic type during program execution (7.3.2.3)
4) Simplify: no need to repeat type parameters
7.3.2.2 TYPE type specifier
..
3 An entity that is declared using the TYPE(*) type specifier is
assumed-type and is an unlimited polymorphic
entity. It is not declared to have a type, and is not considered
to have the same declared type as any other entity,
including another unlimited polymorphic entity. Its dynamic type
is assumed from its effective argument.
>> note: N2123 Fortran 2015 draft says "Its dynamic type and type
parameters are assumed from its effective argument"
5) No change needed
7.3.2.3 CLASS type specifier
..
7 The dynamic type of an allocated allocatable polymorphic object
is the type with which it was allocated. The
dynamic type of an associated polymorphic pointer is the dynamic
type of its target. The dynamic type of a
nonallocatable nonpointer polymorphic dummy argument is the
dynamic type of its effective argument. The
dynamic type of an unallocated allocatable object or a
disassociated pointer is the same as its declared type. The
dynamic type of an entity identified by an associate name
(11.1.3) is the dynamic type of the selector with which
it is associated. The dynamic type of an object that is not
polymorphic is its declared type.
6) Simplify: no need to include kind type parameters, it is implied
from the definition of dynamic type
7.5.6.2 The finalization process
..
12 Only finalizable entities are finalized. When an entity is
finalized, the following steps are carried out in sequence.
(1) If the dynamic type of the entity has a final subroutine
whose dummy argument has the same rank as the entity
being finalized, it is called with the entity as an actual argument.
>> note: N2123 2015 draft says "whose dummy argument has the
same kind type parameters and rank"
7) No change needed
NOTE 7.51
The DEFERRED attribute (7.5.5) defers the implementation of a
type-bound procedure to extensions of
the type; it can appear only in an abstract type. The dynamic type
of an object cannot be abstract;
therefore, a deferred type-bound procedure cannot be invoked. An
extension of an abstract type need not
be abstract if it has no deferred type-bound procedures.
8) Simplify: no need to repeat type parameters
7.5.8 Derived-type values
1 The component value of
* a pointer component is its pointer association,
* an allocatable component is its allocation status and, if it is
allocated, its dynamic type, bounds and value, and
* a nonpointer nonallocatable component is its value.
>> note: N2123 Fortran 2015 draft says "its dynamic type and type
parameters"
9) No change needed
7.5.10 Construction of derived-type values
..
7 If the component is allocatable and the expression is an
allocatable entity, the corresponding component of the
constructor has the same allocation status as that allocatable
entity. If it is allocated, it has the same bounds;
if a length parameter of the component is deferred, its value is
the same as the corresponding parameter of the
expression. If the component is polymorphic, it has the same
dynamic type and value; otherwise, it has the value
converted, if necessary, to the declared type of the component.
8 If the component is allocatable and the expression is not an
allocatable entity, the component has an allocation
status of allocated and the same bounds as the expression; if a
length parameter of the component is deferred,
its value is the same as the corresponding parameter of the
expression. If the component is polymorphic, it has
the same dynamic type and value; otherwise, it has the value
converted, if necessary, to the declared type of the
component.
10) No change needed
7.8 Construction of array values
..
4 The dynamic type of an array constructor is the same as its declared type.
11) Simplify: no need to repeat type parameters
8.5.19 VOLATILE attribute
..
1 The VOLATILE attribute specifies that an object may be
referenced, defined, or become undefined, by means
not specified by the program. A pointer with the VOLATILE
attribute may additionally have its association
status, dynamic type, and array bounds changed by means not
specified by the program.
An allocatable object with the VOLATILE attribute may
additionally have its allocation status, dynamic type
and *deferred* type parameters, and array bounds changed by
means not specified by the program.
>> note: N2123 Fortran 2015 draft says "dynamic type and type parameters"
12) Simplify: no need to repeat type parameters
9.7.1 ALLOCATE statement
..
11 If type-spec is specified, each allocate-object is allocated
with the specified dynamic type;
if source-expr is specified, each allocate-object is allocated
with the dynamic type of source-expr;
otherwise, each allocate-object is allocated with its dynamic
type the same as its declared
type.
13) Simplify: no need to repeat type parameters
9.7.1.2 Execution of an ALLOCATE statement
..
3 If an allocation specifies a coarray, its dynamic type shall be
the same on every active image in the current team.
The values of corresponding bounds and corresponding cobounds
shall be the same on those images. If the coarray
is a dummy argument, its ultimate argument (15.5.2.3) shall be
the same coarray on those images.
14) No change needed
NOTE 9.21
When a NULLIFY statement is applied to a polymorphic pointer
(7.3.2.3), its dynamic type becomes the
same as its declared type.
15) Simplify: no need to repeat type parameters
9.7.3.3 Deallocation of pointer targets
..
2 If a pointer appears in a DEALLOCATE statement, it shall be
associated with the whole of an object that was
created by allocation. The pointer shall have the same dynamic
type as the allocated object,
and if the allocated object is an array the pointer shall be an
array whose elements are the same as those of the
allocated object in array element order. Deallocating a pointer
target causes the pointer association status of any
other pointer that is associated with the target or a portion of
the target to become undefined.
>> note: N2123 Fortran 2015 draft says "The pointer shall have
the same dynamic type and type parameters as the allocated object"
16) Simplify: remove bullet 4) altogether from paragraph 2
10.1.6 Defined operations
10.1.6.1 Definitions
2 A function defines the unary operation op x2 if
(1) the function is specified with a FUNCTION (15.6.2.2) or
ENTRY (15.6.2.6) statement that specifies one
dummy argument d2,
(2) either
(a) a generic interface (15.4.3.2) provides the function
with a generic-spec of OPERATOR (op),
or
(b) there is a generic binding (7.5.5) in the declared type
of x2 with a generic-spec of OPERATOR (op)
and there is a corresponding binding to the function in the
dynamic type of x2,
(3) the type of d2 is compatible with the dynamic type of x2,
(4) either
(a) the rank of x2 matches that of d2 or
(b) the function is elemental and there is no other function
that defines the operation.
>> note: N2123 Fortran 2015 draft has bullet (4) that says
"the type parameters, if any, of d2 match the
corresponding type parameters of x2, and"
---------------------------------------------
There are additional 25 or so instances where "dynamic type" appears
in the standard text, but I feel the theme is the same as captured
above i.e., one can either simplify the standard text and not have to
spike out the "and type parameters" bit or that no change to the text
is needed.
To elaborate further, please consider item 15) above where under
9.7.3.3 Deallocation of pointer targets, N2123 Fortran 2015 draft says
"The pointer shall have the same dynamic type and type parameters as
the allocated object". Or 16) above where the additional definition
of what the function for an unary operation does has to be included
for type parameters in a separate bullet.
The above two instances 15) and 16) in essence show the point I'm
trying to make which is that when dealing with a dynamic type, the
type parameters go along with the type just like horse and carriage.
So why not state as such in the very definition of "dynamic type"?
Sure all this can be quite a bit to digest and even come across as
counter-intuitive, but I will appreciate greatly if some readers,
including a few on the standard committee, will at least take a look
at this and see if it can be brought up for consideration, say, for a
future revision to the standard
Coming back to the top of this thread with SAME_TYPE_AS intrinsic, my
hope is ultimately the standard-conforming behavior will be how Intel
Fortran works today with derived types (as well as intrinsic types but
more on this later), for it is what I think is most useful for coders.
And a further point I would suggest for readers is the arguments that
these are of marginal usefulness or that it is a waste of time are not
healthy in the long term for Fortran. Anything that has the potential
to simplify the standard text and make it easier for compiler
implementations and coders to absorb and work with the language
semantics is of immeasurable value, the benefits accrue over time and
they can prove priceless. And it helps when Fortranners are open to
discussing ideas and options to improve the language and to foster an
open, collaborative environment.
Thanks much for your attention,
Vipul Parekh
|
