From J.L.Schonfelder@liverpool.ac.uk Wed Jun 22 03:27:46 1994 Received: from mailhub.liverpool.ac.uk (mail.liv.ac.uk) by dkuug.dk with SMTP id AA04461 (5.65c8/IDA-1.4.4j for ); Wed, 22 Jun 1994 11:28:04 +0200 Received: from liverpool.ac.uk by mailhub.liverpool.ac.uk with SMTP (PP) id <11464-0@mailhub.liverpool.ac.uk>; Wed, 22 Jun 1994 10:27:34 +0100 Date: Wed, 22 Jun 1994 10:27:46 PDT From: Lawrie Schonfelder Subject: Generic Dummy Procedure Arguments 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 References: none Generic Dummy Procedures 1 Introduction The question of dummy procedures where the specific name passed was that of a member of a generic set with the same name has been raised recently on the network. The request made as a requirement was that user generic procedures should be treated similarly to intrinsic procedures, viz. that as the specific procedure name SIN can be passed as an actual argument to a dummy procedure this capability should also be allowed for a user defined procedure whose name was both that of a specific procedure and a whole generic set. In this paper I would like to propose a much more radical but also more useful extension. I believe that with very little actual change to the language we could, and indeed should, allow the declaration of generic dummy procedures and hence allow generic names to appear as actual arguments. A major requirement for such a facility arises from the use of the generic functionality along with KIND parameterisation to provide for programs which are essentially portable against precision changes. This capability currently breaks down in two areas:  the lack of parameterised datatypes which requires different types with different names to be defined for each kind destroying the source level portability that KIND provides for intrinsic types, and  the fact that only specific procedures can be passed as procedure arguments means that again precision specific names must be used; generic names can only be communicated globally. The proposal already before the committees on parameterised datatypes aims to correct the former deficiency and this proposal is aimed at fixing the latter. 2 Technical Description The basic linguistic apparatus required already exists in the language. What is needed is a mechanism to declare the generic procedure nature of the dummy argument and to specify the characteristics of each specific procedure that must form part of the overload set. This is precisely what is done by a generic interface block. It is merely necessary to allow such a construct to be used to declare the nature of a dummy argument. The semantics of such a device are also quite obvious. An actual argument matching such a dummy argument must be a generic procedure name. The overload set referenced by this actual generic name must contain specific procedures matching the characteristics (but not necessarily the names) of the dummy overload set specific procedures. The actual overload set may contain additional overloads. This would not matter as these could not be accessed within the procedure, but since any of those specified for the dummy generic set could be, matches for all these must be specified for the actual argument. The outcome of a successful invocation of the procedure would be to match by characteristic each of the dummy specific procedures with the corresponding actual specific procedure. These would be the procedures subsequently invoked by references to the dummy generic procedure in the body of the procedure. 3 Proposed Edits to IS 1539 : 1991 3.1 12.2.12 [166/9] After "explicit" add "if it is generic," [166/9+] Add sentence "If the dummy procedure is declared by a generic interface, it is generic and the characteristics of each of its specific procedures are characteristics of the dummy procedure." 3.2 12.3.1.1 [167/2] After "array" add "a generic dummy procedure," 3.3 12.3.2.1 [167/44+] Add sentence "If the generic name on an interface block is that of a dummy argument, the interface block declares this argument to be a generic dummy procedure. The interface bodies contained in the block specify the characteristics for the specific dummy procedures associated with this generic dummy procedure. " 3.4 12.4.1.2 [173/31] After "is a" add " specific" [173/41+] Add paragraph "If a dummy argument is a generic dummy procedure, the associated actual argument must be the generic name of a set of specific procedures. The set of procedures so referenced must contain procedures whose characteristics match those specified to form part of the dummy generic set. The actual argument generic set may contain additional specific procedures but these are not associated with any dummy procedure and are not made accessible by the association." I believe these edits to be sufficient but I have not done an exhaustive search of the standard to check that there are no other possible places which need changes. 4 Proposal I would like to propose that WG5 consider this as a proposal for an extension to be included either in F95 or in F2000, preferably the former. -- 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