From jwagener@trc.amoco.com Tue Aug 25 00:09:34 1992 Received: from noc.msc.edu by dkuug.dk via EUnet with SMTP (5.64+/8+bit/IDA-1.2.8) id AA16420; Tue, 25 Aug 92 00:09:34 +0200 Received: from uc.msc.edu by noc.msc.edu (5.65/MSC/v3.0.1(920324)) id AA20921; Mon, 24 Aug 92 17:09:40 -0500 Received: from [129.230.11.2] by uc.msc.edu (5.65/MSC/v3.0z(901212)) id AA17422; Mon, 24 Aug 92 17:09:39 -0500 Received: from trc.amoco.com (apctrc.trc.amoco.com) by netserv2 (4.1/SMI-4.0) id AA00302; Mon, 24 Aug 92 17:09:16 CDT Received: from crmac1 by trc.amoco.com (4.1/SMI-4.1) id AA11437; Mon, 24 Aug 92 17:09:34 CDT Date: Mon, 24 Aug 92 17:09:34 CDT Message-Id: <9208242209.AA11437@trc.amoco.com> From: Jerrold L. Wagener To: SC22WG5@dkuug.dk Subject: 92-183: Object-Oriented Extensions to Pascal [and Fortran] X-Charset: ASCII X-Char-Esc: 29 As indicated in my earlier note, here is a draft version of X3J3/92-183 for those interested in OOP to sink their teeth into. Jerry * * * * * * * * begin 92-183 * * * * * * * * References: X3J9/92-028 ISO/IEC JTC1/SC22/WG2 N317 The referenced report, copies to be brought to X3J3 meeting 123 (Nov 9-13, 1992, New Haven, CT), describe in detail the proposed extensions to Pascal to provide object-oriented capability. It is currently in draft form, being processed as a formal ANSI technical report. Though a report this large (65 pages) and of this nature would normally not be included among the X3J3 documents, the considerable interest in investigating object-oriented facilities appropriate for Fortran seem to justify inclusion in this case. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * In reviewing this draft report I was struck (again) by how much of the practical functionality of object-oriented programming Fortran 90 already possesses, especially if a few (rather minor) deficiencies of derived types are resolved. Though OO purists will no doubt disagree and object, I believe that a very rudimentary yet legitimate object-oriented capability in Fortran requires only two minor syntactic additions to Fortran 90. No significant conceptual or semantic changes are needed, as the derived type (with those deficiencies repaired) and generic procedure mechanisms of Fortran 90 already provide the principal functionality involved in object-oriented techniques. These two syntactic additions allow: (a) new types to inherit operations (typically called RmethodsS in OO jargon) as well as object definitions associated with other types, (b) methods to be included in and become part of type definitions, and (c) object-specific method activation in typical object- oriented fashion. An OO method may be thought of as merely a Fortran 90 generic procedure in which the type with which the method is associated is one of the factors in resolving procedure references. Thus the generic procedure mechanisms already in Fortran 90 can provide for OO methods. The object-oriented way of invoking these procedures, sometimes called method activation, tends to be object- specific and focuses as much attention on the object involved as upon the method being invoked. The two syntactic additions, therefore, are optionally allowing: (1) generic-name interface blocks as additional RcomponentsS in derived type definitions (the generic-name is called the method-name in the syntax below, so effectively method names become additional components of the derived type) (2) both function and subroutine calls of the form Rdata-ref%method-nameS (i.e., extending standard Fortran 90 structure component syntax) in which a method component is applied to an object of that type (i.e., a method component reference, rather than but in analogy to a data component reference) The Two Syntax Additions The first extends R422: derived-type-def is derived-type-stmt [ private-sequence-stmt ]... [ component-def-stmt ]... [ method-def ]... end-type-stmt with the corresponding new syntax rules: method-def is INTERFACE method-name method-interface END INTERFACE method-interface is interface-body or MODULE PROCEDURE procedure-name constraint: The procedure specified in a method-interface must have at least one dummy argument, and the first dummy argument must be a non-optional scalar data object of the derived type which contains this method-interface. If the procedure is a function the first dummy argument must have intent IN; if the procedure is a subroutine the first dummy argument must have intent IN/OUT. <..then need to mention, following R422, that a method-def is merely a restricted form of R1201, with a generic-spec (i.e., method-name) equivalent to generic-name..> The second extends R1209 and R1210: function-reference is function-name ( [ actual-arg-spec-list ] ) or data-ref % method-name ( [ actual-arg-spec-list ] ) call-stmt is CALL subroutine-name [ ( [ actual-arg-spec-list ] ) ] or data-ref % method-name [ ( [ actual-arg-spec-list ] ) ] constraint: The right-most part-name in data-ref must be a derived-type object whose type definition specifies a method-interface for method-name. <..then the following semantics need to be specified somewhere following R1210..> method-name is a generic procedure name and the reference is resolved according to the rules in 12.3.2.1 and 14.1.2.3. In resolving such references, and in executing the reference, the data object specified by data- ref becomes associated with the first dummy argument of the procedure and the entities in the actual argument list itself become associated with the remaining dummy arguments - that is, the first actual argument becomes associated with the second dummy argument, the second actual argument with the third dummy argument, and so on. <..these semantics also need to be included as well in the 12.3.2.1 discussion of generic procedures and resolving references to them..> * * * * * * * * end 92-183 * * * * * * * *