There is some indication from a recent thread on this mailing list the
Fortran standards committee might be open to the idea of an alternate
constructor for a COMPLEX type in a future revision and that it will
require further careful work:
On Tue, Jun 6, 2017 at 4:12 AM, Malcolm Cohen
<mailto:[log in to unmask]> wrote:
>> ..
>
> It would be better to have an alternative constructor that can be used instead of CMPLX. It will require some careful work to achieve, ..
On Tue, 6 Jun 2017 10:00:16 +0900, Malcolm Cohen
<mailto:[log in to unmask]> wrote:
>> ..
>
> Based on past experience it will need some careful design work if it is to have any chance of achieving consensus though!
Given this background, it is requested of the committee, should they
embark on such a task, to consider:
a) Naming the alternate constructor COMPLEX itself,
b) That it be a true constructor, not yet another TYPE CONVERSION function, and
c) The constructor have rules and semantics that match those that
exist with a complex-literal-constant in the current standard.
That is, the constructor will simply be
--------------------------------------------
COMPLEX( real-part, imag-part )
where
real-part is variable
or signed-int-literal-constant
or signed-real-literal-constant
or named-constant
imag-part is variable
or signed-int-literal-constant
or signed-real-literal-constant
or named-constant
Each variable in a complex constructor shall be of type integer or real.
Each named constant in a complex constructor shall be of type
integer or real.
If the real part and the imaginary part of a complex constructor are
both real, the kind type parameter value of the constructor result is
the kind type parameter value of the part with the greater decimal
precision; if the precisions are the same, it is the kind type
parameter value of one of the parts as determined by the processor.
If both the real and imaginary parts are integer, they are converted
to the default real approximation method and the constructor result is
default complex. If only one of the parts is an integer, it is
converted to the approximation method selected for the part that is
real and the kind type parameter value of the constructor result is
that of the part that is real.
--------------------------------------------
The rationale being if one considers the use case of an alternate
constructor for a COMPLEX type, it will be that coders presently have
three ways to construct an object of complex type in Fortran: one with
the direct use of a complex-literal-constant, second using an
expression involving a complex-literal-constant, and a third way using
the CMPLX intrinsic type conversion function. The first two
approaches do not meet all the needs of coders, thus they have to
resort to the third approach using the CMPLX intrinsic; however, there
is evidence of coders paying insufficient attention of the details of
this function and introducing errors in the process. The motivation
to introduce an alternate constructor will be to overcome the
deficiencies of the existing facilities, especially those involving
the CMPLX function.
Toward this, it is important to note a complicated set of rules
already exist with the construction of a complex type with the
complex-literal-constant. Implementers and coders thus face the
burden of keeping track of several kind type conversion possibilities
with this constant, but the fact is these rules have been part of the
language for a considerable period of time already. It will therefore
be of great help to coders if they are allowed to follow, as much as
possible, the same thought process in their use of the alternate
constructor rather than have to learn of a new set of type coercions.
This should then allow them the following:
-- begin pseudo code snippet --
..
<real or integer of arbitrary kind>, parameter :: FOO = ..
<real or integer of arbitrary kind>, parameter :: BAR = ..
..
<real or integer> :: foo_ = FOO ! Say same type and kind as FOO
<real or integer> :: bar_ = BAR ! Say same type and kind as BAR
..
.. ( FOO, BAR ) !<- Allowed; view as this some stmt where
complex constant appears
!.. ( foo_, bar_ ) !<-- This is not allowed per current standard
..
.. COMPLEX( FOO, BAR ) !<-- Will be allowed and yield the same
result as ( FOO, BAR )
.. COMPLEX( foo_, bar_ ) !<-- Will be allowed and yield the same
result as ( xx, yy ) where
! xx and yy can be viewed as
named constants of the same
! type and kind and holding
the same value as foo_ and bar_ respectively
! as in FOO and BAR above
..
-- end snippet --
Thank you,
Vipul Parekh
|