(j3.2006) LinkedIn Question re Why TYPEALIAS Not in Fortran 2003

Van Snyder Van.Snyder
Mon Jan 27 16:44:10 EST 2014


On Mon, 2014-01-27 at 20:10 +0000, Bill Long wrote:

> On Jan 27, 2014, at 1:50 PM, Van Snyder <Van.Snyder at jpl.nasa.gov> wrote:
> 
> > On Mon, 2014-01-27 at 13:00 +0000, Bill Long wrote:
> >> On Jan 25, 2014, at 8:01 PM, Van Snyder <van.snyder at jpl.nasa.gov>
> >> wrote:
> >> 
> >>> On Sat, 2014-01-25 at 18:48 -0600, Craig Dedo wrote:
> > 
> >>>>           I have forgotten why TYPEALIAS was dropped late in the
> >>>> process.  Does anyone remember why this happened?
> >>> 
> >>> 1.  It was the wrong thing to do.  New types (not synonymns) are more
> >>> useful, and can do everything that type aliases can do -- but not vice
> >>> versa.
> >> 
> >> Certainly not true.  You cannot make a new intrinsic type, which leads
> >> to clumsy hacks when trying to map typedefs in C. 
> > 
> > This isn't a problem if you do it right.  You model new types on type
> > extension, with the same sort of compatibility rules.


I was careful to write "model new types on type extension," not "use
type extension exactly as it was implemented in 2003."


> I must be missing some trick in how to accomplish the simplest ?poster child? application of typealias.  I want 


I went through this several years ago with Aleks Donev.  I guess you
weren't in the room.


> type(MPI_Comm) :: x
> 
> to be equivalent to



You don't want it to be equivalent.


> INTEGER(C_INT) :: x
> 
> or, if you prefer
> 
> type(INTEGER(C_INT)) :: x
> 
> to mimic the C header file that contains
> 
> typedef int MPI_Comm;
> 
> How, exactly, do I do this using type extension?


  Here's exactly how you do it:


  type :: MPI_Comm => integer(c_int)        ! or type(integer(c_int))

  ! MPI_Comm is now type compatible with integer(c_int).  It has no free type parameters.

  interface
    subroutine My_C_Sub ( Arg ) bind(C)
      import :: MPI_Comm
      type(MPI_Comm), value :: Arg
    end subroutine My_C_Sub
  end interface


It is possible to call MY_C_Sub with arguments of type MPI_Comm, but not
arguments of type integer(C_Int).  If you absolutely need to pass an
integer, use the type constructor:

  call MY_C_Sub ( MPI_Comm(42_c_int) )

In a type definition statement, if the base type is C interoperable, so
is the extended type.

One reason to want new types instead of type synonyms is the problem of
kinds.

Suppose one develops two approximations for, say, Fresnel integrals.
One uses a 5-6 Pad? approximation, and it's accurate to, say, eight
digits.  The other uses a 12-13 Pad? approximation and is's accurate to,
say, 16 digits.  One is defined with a SELECTED_REAL_KIND(7) dummy
argument, and the other with a SELECTED_REAL_KIND(14) argument.  This
all works fine until the code is schlepped to a platform where those are
the same kind type parameter values.  It won't even compile!  (Yes, this
has already happened to me.)  But if one could define

  type(My_Real_7) => real(selected_real_kind(7))
  type(My_Real_14) => real(selected_real_kind(14))

and these are different types, even if selected_real_kind(7) ==
selected_real_kind(14), the code still compiles and works.  This cannot
be done with type synonyms.

Because of our rules for type compatibility (with slight adjustment, so
that an object of a base type is compatible with objects of new types
defined from it, even if it's not polymorphic), and inheritance (maybe
with slight adjustment so that types based on intrinsic types inherit
intrinsic operations -- unless they're overridden), objects of
type(my_real_7) can be actual arguments to procedures with dummy
arguments of type(real(selected_real_kind(7))), but not vice versa.  So
all the intrinsic operations and functions are available, and if you
happen to have, for example, a generic quadrature routine with types
real(kind(0.0e0)) and real(kind(0.0d0)), you can use it, too.

This scheme is also useful for producing new types that have fewer free
type parameters from base types.  It is frequently necessary to specify
exactly the same value throughout an application (or part of one) for
some subset of the parameters of a type, but it's possible for some to
drift away from identity during maintenance.  With a new type, for which
the parameters you want to be identical tied down in the type
definition, this cannot happen.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.j3-fortran.org/pipermail/j3/attachments/20140127/17dde010/attachment.html 



More information about the J3 mailing list