From owner-sc22wg5 Sun Sep 8 21:40:46 2002 Received: from Princeton.EDU (postoffice.Princeton.EDU [128.112.129.120]) by dkuug.dk (8.9.2/8.9.2) with ESMTP id VAA17106 for ; Sun, 8 Sep 2002 21:40:45 +0200 (CEST) (envelope-from adonev@Princeton.EDU) Received: from smtpserver1.Princeton.EDU (smtpserver1.Princeton.EDU [128.112.129.65]) by Princeton.EDU (8.12.3/8.12.3) with ESMTP id g88Jbcj5023852; Sun, 8 Sep 2002 15:37:38 -0400 (EDT) Received: from princeton.edu (ppp642.mt.net.mk [62.220.194.42]) (authenticated bits=0 netid=adonev) by smtpserver1.Princeton.EDU (8.12.2/8.12.2) with ESMTP id g88JbMFY010518 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 8 Sep 2002 15:37:34 -0400 (EDT) Message-ID: <3D7BA6F1.94670665@princeton.edu> Date: Sun, 08 Sep 2002 15:37:21 -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 not complete 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. 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). 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. J3 may have discussed this when I was not around, but here is my take: 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) TYPE(INTEGER, REAL), KIND :: Numeric_Type ! Must be either INTEGER or REAL INTEGER, KIND :: numeric_kind ! The kind of the type 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: TYPE(INTEGER, REAL), KIND :: Numeric_Type ! Must be either INTEGER or REAL INTEGER, KIND :: numeric_kind ! These are the dummy arguments TYPE(Heap(Numeric_Type,numeric_kind,*)), INTENT(INOUT) :: heap Numeric_Type(numeric_kind), INTENT(IN) :: element ... END SUBROUTINE InsertInHeap Now, one can make a real procedure out of this (which needs no body): INSTANCE(INTEGER, i_single) SUBROUTINE InsertInHeap which can also be included in interface blocks, such as: INTERFACE InsertInHeap MODULE INSTANCE(INTEGER, i_word) PROCEDURE InsertInHeap MODULE INSTANCE(REAL, r_single) PROCEDURE InsertInHeap MODULE INSTANCE(REAL, r_double) PROCEDURE InsertInHeap END INTERFACE Again, please don't focus on the syntax---I am trying to convey the idea here: It is possible to have template-like functionality without the C++ havoc where one can make instances as one pleases. The above is really something one can (and does do in F95) with a code-generating macro, but integrated into the language, with all the efficiency and compile-time checking that one would have with the macro-based approach. I find it a neccessity daily, and though I love macroing, I feel it is not suitable for something so fundamental. Thanks for reading if you got this far! 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 __________________________________