From owner-sc22wg5 Sun Sep 8 23:00:42 2002 Received: from Princeton.EDU (postoffice.Princeton.EDU [128.112.129.120]) by dkuug.dk (8.9.2/8.9.2) with ESMTP id XAA17522 for ; Sun, 8 Sep 2002 23:00:41 +0200 (CEST) (envelope-from adonev@Princeton.EDU) Received: from smtpserver2.Princeton.EDU (smtpserver2.Princeton.EDU [128.112.129.148]) by Princeton.EDU (8.12.3/8.12.3) with ESMTP id g88Kufj5002406; Sun, 8 Sep 2002 16:56:41 -0400 (EDT) Received: from princeton.edu (ppp701.mt.net.mk [62.220.194.101]) (authenticated bits=0 netid=adonev) by smtpserver2.Princeton.EDU (8.12.2/8.12.2) with ESMTP id g88KuZ2e007369 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 8 Sep 2002 16:56:37 -0400 (EDT) Message-ID: <3D7BB984.A382569F@princeton.edu> Date: Sun, 08 Sep 2002 16:56:36 -0400 From: Aleksandar Donev Organization: Princeton University X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: J3 , WG5 CC: Aleksandar Donev Subject: Generics and Templates in F2x Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, I have been writing some programs in the past few months and tried to write them in both F95 and F2x (using macroing) in order to see how F2x new features help and work in real coding (though of course I cannot test the efficiency). I am sharing some findings with you hoping for some discussion. Think of these as issues for the future versions after F2x (though some can and maybe should be addressed now), or simply as my (unofficial) public comment to the CD draft. 1. First, a simple question which I cannot dig out the answer for: Can one use KIND as the name of a kind type parameter? TYPE :: IntegerHeap(KIND) INTEGER, KIND :: KIND ... ENDTYPE IntegerHeap I want to be able to because it parallels Fortran intrinsic things. But it may be forbidden somewhere I have missed. 2. One should be able to include generics inside other generic interface blocks. It seems to me there is no way at present do so something like this: INTERFACE InsertInIntegerHeap ...! A list of specifics END INTERFACE INTERFACE InsertInRealHeap ...! A list of specifics END INTERFACE Now I want to unite these into one, using something alike: INTERFACE InsertInHeap GENERIC InsertInIntegerHeap GENERIC InsertInRealHeap END INTERFACE I do not see why this was not built in the design of F2x? It really is a very nice feature that finds many uses. 3. This is the thorniest issue and one which I think is most important: I am finding the lack of something alike C++ templates a big handicap. Now, C++ templates have there own problems. But at the very least, a kind of a built-in specific generation mechanism is needed in the language. I, and I am sure many others, extensively use macros in order to generate specific routines to be later put in a generic interface. However, this often requires overly sophisticated macro techniques and IMHO should really be a part of the language. The real benefits of Fortran generics are of course compile-time resolution and compile-time checks. I think any template-like facility should keep these. Here is one possibility: One can declare a kind parameter of a derived-type which is another type (or a typealias), restricted to a given set of types specified in the declaration: TYPE, TEMPLATE :: Heap(Numeric_Type, numeric_kind, N) INTEGER, KIND :: numeric_kind ! The kind of the type TYPE(INTEGER, REAL), KIND :: Numeric_Type ! Must be either INTEGER or REAL INTEGER, NONKIND :: N ! The heap size Numeric_Type(numeric_kind), DIMENSION(:), POINTER :: heap ! The actual heap order ... ENDTYPE Of course, I have not considered the syntax carefully, so ignore the flaws in it. The idea is that unlike in C++ templates, we are specifying what kinds can be used when instantianting the template. Therefore, the above declaration is equivalent to declaring two different parameterized types, one for an IntegerHeap, the other for a RealHeap. In fact, it should be compiled that way. It is just like the user used a macro to make these two different derived types using the above template, only the compiler does it automatically. A similar facility would be provided for declaring procedures which can have arguments which are templated types. Unlike in C++, where the compiler needs to create the instances when it sees a usage of the given function, I think it is better to treat templated types like parameterized derived types which happen to have a kind parameter which is another type. Therefore, the template for the procedure will not really be a callable procedure, one must make a specific instance where all parameters have fixed kind parameters first by using the template. Something like: TEMPLATE(Numeric_Type, numeric_kind) SUBROUTINE InsertInHeap(heap, element) ! These are the template parameters: INTEGER, KIND :: numeric_kind TYPE(INTEGER, REAL), KIND :: Numeric_Type ! These are the dummy arguments TYPE(Heap(Numeric_Type,numeric_kind,*)), INTENT(INOUT) :: heap Numeric_Type(numeric_kind), INTENT(IN) :: element !... END SUBROUTINE InsertInHeap This template is not a callable routine, but rather one which can be made into a callable specific only by placing it inside an interface block: INTERFACE InsertInHeap INSTANCE(INTEGER, i_word) MODULE PROCEDURE InsertInHeap INSTANCE(REAL, r_single) MODULE PROCEDURE InsertInHeap INSTANCE(REAL, r_double) MODULE PROCEDURE InsertInHeap END INTERFACE Again, please don't focus on the syntax. I am trying to convey the idea here that one can provide a Fortran-spirited template-like facility without the instantiation mess and inefficiency of C++. In fact, what I am proposing above does nothing more then can already be done with some macroing for automatic code generation. But I do believe that integrating this into the language is an important thing, despite there being an alternative external to the language. Thanks for reading if you got this far! Comments please, Aleksandar -- __________________________________ Aleksandar Donev Complex Materials Theory Group (http://cherrypit.princeton.edu/) Princeton Materials Institute & Program in Applied and Computational Mathematics @ Princeton University Address: 419 Bowen Hall, 70 Prospect Avenue Princeton University Princeton, NJ 08540-5211 E-mail: adonev@princeton.edu WWW: http://atom.princeton.edu/donev Phone: (609) 258-2775 Fax: (609) 258-6878 __________________________________