From jwagener@ionet.net Thu Nov 23 20:48:48 1995 Received: from ion3.ionet.net (ion3.ionet.net [204.96.200.8]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id UAA06129 for ; Thu, 23 Nov 1995 20:48:45 +0100 Received: from erehwon (tsip24.ionet.net [206.28.164.33]) by ion3.ionet.net (8.6.12/8.6.12) with SMTP id NAA06970 for ; Thu, 23 Nov 1995 13:48:35 -0600 X-Mailer: InterCon TCP/Connect II 2.2.1 MIME-Version: 1.0 Message-Id: <9511231354.AA09590@erehwon> Date: Thu, 23 Nov 1995 13:54:09 -0500 From: "Jerrold L. Wagener" To: sc22wg5@dkuug.dk Subject: Liaison Report on Parameterized Derived Types Content-Type: Text/Plain; charset=US-ASCII Content-Disposition: Inline X3J3/95-288r1 1995 Nov 17 Liaison Report on Parameterized Derived Types To: WG5, X3J3, and Steve Morgan From: X3J3/oof References: X3J3/95-272 X3J3/95-272, entitled "Data Type Enhancements in Fortran", is the same as WG5 temporary paper S26 at the November 1995 WG5 meeting in San Diego. Sections 3.2 and 4.2 of this paper deal with parameterized derived types and X3J3 believes constitute the most recent proposals for a parameterized derived type facility for Fortran 2000. This facility: -- provides both "kind" and "nonkind" (size) type parameters for derived types -- has a KIND statement to distinguish/specify the kind type parameters -- requires kind type values to be specified by integer scalar initialization expressions -- requires nonkind type values to be specified by specification expressions, or "*" -- has constructor functions patterned after the REAL intrinsic function -- has inquiry functions patterned after the KIND and LEN intrinsic functions -- requires matching type and type parameters (kind and nonkind) for intrinsic assignment -- requires matching type and type parameters (kind and nonkind) for argument association -- allows dummy arguments with "*" nonkind type parameters, which match any actual value -- allows kind type parameters, but not nonkind type parameters, to resolve overloads X3J3 concurs technically with this facility in the following ways: -- both kind and nonkind type parameters are needed -- static kind values in all cases (initialization expressions), including dummy arguments -- dynamic nonkind type values for dummy arguments, in the form of "*" (but see below) -- using the Fortran 95 intrinsic function model of REAL, for constructors (but see below) -- using the Fortran 95 inquiry function models of KIND, and LEN (but see below) -- using the Fortran 95 type and type parameter matching rules in all cases -- allowing (static) kind type parameters to resolve generic overloads Technical concerns regarding this proposal raised with X3J3 include: -- the need for the KIND statement, and syntax alternatives, require further elaboration -- provision for multiple kind type parameters; is more than one really needed? -- impact of the inquiry functions on the namespace -- advisability of renaming both the parameter key words and inquiry function names -- the use of "*" instead of ":" for dummy nonkind parameters; most use will be to size arrays -- implicit typing of parameters in the derived type definition -- use more consistent terminology (e.g., "shape" vs. "order") to aid non-English speakers -- edits are incomplete (e.g., edits don't allow parameters to be keyworded in constructors) -- possible ramifications of changing structure constructors to constructor functions -- no edits to chapter 14 regarding potential impact on namespace Some of these concerns may reflect minor or nonexistent problems; others may be major problems. These concerns have been raised by individuals and subgroups with X3J3 and have not been analyzed in detail by X3J3; the result of any such analysis may conclude there is no problem associated with a specific item or that there are other problems not identified. Despite this lack of detailed analysis, X3J3 believes that this list of concerns should be addressed by the development body for parameterized derived types.