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

[Bill Long]

On Jan 27, 2014, at 3:44 PM, Van Snyder <Van.Snyder at jpl.nasa.gov> wrote:

> 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.
> 


Sorry, but you don?t get to decide what I want.



>> 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))
> 
> 

I don?t recall any syntax like this.  Is this another of your new features?


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

Type compatible is not sufficient.  The compiler has to see the types as the same so that all of the normal optimizations and semantics that apply for INTEGER(C_INT) would also apply to something declared TYPE(MPI_COMM). 

> 
>   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:

Sorry, but this is a solution to a different problem.  Not relevant to this discussion.

Cheers,
Bill



> 
>   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.
> 
> 
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3

Bill Long                                                                       longb at cray.com
Fortran Technical Suport  &                                  voice:  651-605-9024
Bioinformatics Software Development                     fax:  651-605-9142
Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101