From J.L.Schonfelder@liverpool.ac.uk Wed Jun 22 03:26:08 1994 Received: from mailhub.liverpool.ac.uk (mail.liv.ac.uk) by dkuug.dk with SMTP id AA04402 (5.65c8/IDA-1.4.4j for ); Wed, 22 Jun 1994 11:26:18 +0200 Received: from liverpool.ac.uk by mailhub.liverpool.ac.uk with SMTP (PP) id <11342-0@mailhub.liverpool.ac.uk>; Wed, 22 Jun 1994 10:26:10 +0100 Date: Wed, 22 Jun 1994 10:26:08 PDT From: Lawrie Schonfelder Subject: Constructor Enhancements To: SC22/WG5 members Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Charset: ASCII X-Char-Esc: 29 To: X3J3 and WG5 (30-May-94) From: Lawrie Schonfelder Constructor Enhancements 1 Introduction The constructor as defined in F90 has the syntactic form of a function reference but unlike any other intrinsically defined function it cannot be referenced using keyword arguments. This can and does make the constructor a remarkably unfriendly feature of Fortran 90 to use, particularly with a structure that is large with a long list of different components. The proposal is to allow the use of component names as keywords in a constructor reference. 2 Technical Description 2.1 Keyword arguments in constructors The aim here is to make the references to constructors more user friendly, especially when structures having a large number of components are constructed. The proposal also makes the syntactic similarity between a function reference and constructor reference more complete thus removing a source of user irritation if not confusion. The intent is to help the user to specify the expression/component correspondence using either positional or keyword argument syntax, with the keywords being the component names. For example, given a type defined by TYPE STOCK_ITEM INTEGER :: id,holding,buy_level CHARACTER(LEN=20) :: desc REAL :: buy_price,sell_price ENDTYPE STOCK_ITEM the two constructor references below would mean the same thing. STOCK_ITEM(12345,75,10,"Pencils HB",1.56,2.49) STOCK_ITEM(desc="Pencils HB", id=12345, & holding=75, sell_price=2.49, & buy_level=10, buy_price=1.56 ) The latter is substantially more indicative of the intent of the reference. It makes the correspondence between component and expression obvious. The keyword form also provides an indication of the underlying assignment semantics that applies to the component=expression correspondence. However, when considered as a function reference the assignment semantics in effect mean that the constructor name is generic with the set of overloads defined as per the valid assignments. For pointer components the keyword would still be the component name and the component= form used although now the intrinsic assignment semantics implied are those of pointer assignment and the expression must deliver a result that has the target attribute. This is again exactly what would be required for a function reference where the corresponding dummy argument was either a pointer or a target. As with function reference actual arguments, positional correspondence should be permitted up to the first use of the keyword form, all subsequent component/expression arguments would have to be of the keyword form. {{{ Note, When parameterised data types are added the only addition to this proposal that is needed is that the type parameter names may be used as keywords to indicate the correspondence for parameter value expressions in the extended constructor. In fact this proposal makes even more sense in this context since it allows the user to order type-parameter and component expressions as is most convenient to them. }}} 2.2 Allowing user defined overloads There would also be significant advantages in actually defining the constructor to be a generic function. The most important of these advantages is that of allowing the users to provide their own overloads for the constructor name. For example, suppose we set up a type for rational arithmetic, TYPE RAT INTEGER :: num,den ENDTYPE RAT The intrinsic constructor would be, RAT(22,7) or RAT(num=22,dem=7) It would be desirable with such a type to have routines that convert from say a real value to a rational number representation and it would be desirable for this conversion to have the name RAT. With the above definition it would be legal to write a generic interface block, INTERFACE RAT FUNCTION real_to_rat(real) REAL,INTENT(IN) :: real type(RAT) :: real_to_rat ! convert real to the rational representation ENDFUNCTION real_to_rat ENDINTERFACE This proposal provides a further significant piece of the OOF technology that will be essential for the long term health of Fortran as a serious application development language. 3 Proposed Edits to IS 1539 : 1991 These edits are proposed as an indication to the editorial committee as to the sort of changes that would be necessary to implement these proposals. 3.1 Keywords in constructors edits 3.1.1 4.4.4 [37/5] Replace "expr-list" with "comp-expr-list" Add R430.1 comp-expr is [component-name=]expr Constraint: Each component-name must be the name of a component specified in the type definition for the type-name. Constraint: The component-name= may be omitted only if it has been omitted from each preceding comp-expr in the comp-expr-list. 3.1.2 4.4.4 [37/7] After "type." add sentence The correspondence between expression and component may be indicated by the component name appearing explicitly in the form of a keyword in a manner similar to procedure argument association (12.4.1). 3.2 Constructor as generic function 3.2.1 4.4.4 [37/2] After "corresponding" add "generic function reference that is a" 4 Proposal That constructors be defined to be generic functions and component names be permitted as keywords in any constructor reference as defined above and that this functionality be added to Fortran 95. -- Dr.J.L.Schonfelder Director, Computing Services Dept. The University of Liverpool, UK e-mail J.L.Schonfelder@liv.ac.uk phone: +44(51)794-3716 fax: +44(51)794-3759