From LJM@SLACVM.BITNET Tue Aug 23 04:56:00 1994 Received: from vm.uni-c.dk by dkuug.dk with SMTP id AA19351 (5.65c8/IDA-1.4.4j for ); Wed, 24 Aug 1994 03:14:01 +0200 Message-Id: <199408240114.AA19351@dkuug.dk> Received: from vm.uni-c.dk by vm.uni-c.dk (IBM VM SMTP V2R2) with BSMTP id 3709; Wed, 24 Aug 94 03:13:50 DNT Received: from SLACVM.SLAC.STANFORD.EDU by vm.uni-c.dk (Mailer R2.07) with BSMTP id 2459; Wed, 24 Aug 94 03:13:49 DNT Received: by SLACVM (Mailer R2.08 R208004) id 8894; Tue, 23 Aug 94 13:12:21 PST Date: Tue, 23 Aug 1994 12:56 -0800 (PST) From: "Len Moss" To: "SC22/WG5 Mailing List" Subject: Comments on OO requirements in 94-004r3s and N970 X-Charset: ASCII X-Char-Esc: 29 Forwarded-from: LJM On 15 August 94, I received the following comments from William Clodius on various requirements in the X3J3 JOR (94-004r3s) and WG5 Repository (N970) that are related to object-oriented programming. It was clearly too late to get them to anyone in time for consideration at the August meetings (note, BTW, that they were only sent on 13 Aug), so I postponed dealing with them while I took care of some more pressing SLAC business. I couldn't tell whether Mr. Clodius sent these comments to others besides myself, so my apologies if you get them more than once. PS: Mr. Clodius mentions below a longer paper discussing OO issues. He sent me this paper as well, and I'll be happy to forward it if there is interest. It's about 1350 lines in total (sent in 3 parts). - - - - Forwarded Text - - - - Date: Sat, 13 Aug 1994 19:27:50 -0400 (EDT) From: William Clodius <71022.1165@compuserve.com> Subject: 94-004r3s and N970 To: ljm@SLAC.Stanford.EDU Message-id: <940813232749_71022.1165_CHJ41-1@CompuServe.COM> Dear Len Moss, Jeanne Martin, J.L. Schonfelder, Craig Dedo, and members of X3J3 and WG5 Appologies if this is the second time you recieve this. I am having trouble with American Online and decided to try Compuserve. I wish to comment on the following requirements: in X3J3/94-004r3s the requirements: 033 Object Oriented Fortran, OOF 043 OOP Capabilities 049 Generalize Constructors into Generic Procedures 059 Pointers to Procedures and in ISO/IEC JTC1/SC22/WG5 - N970 the requirements: 11 Aliasing Type Definitions 14, 14a Parameterized Derived Types 16 Allow Alocatable derived-type components 18 Object Oriented Programming and to make some general comment about object oriented Fortran. These comments are inspired by an email message in May from Schonfelder detailing his proposal, X3J3-129/94-xxx, for parameterized user defined types. I found this proposal interesting and exciting, but with some problems. I hope this message arrives before the August meeting, but it has taken me some time to formulate my thoughts. In addition to briefer comments given below, I will latter send a long paper expounding on these thoughts, in pure text format. Because of time constraints, this paper, particularly the later part of the paper, is not complete. It is probably overly ambitious for the short time scale available for Fortran 9x and too long for most members of the committee to examine. Still I believe it will be of interest to Schonfelder and may be of interest to other members of the OOF committee for its insight into some ways that Fortran could develop. Specific comments on the available requirements. in X3J3/94-004r3s 033, Object Oriented Fortran, OOF, mentions, among other things, constructors, destructors, user defined polymorphism, libraries, abstract classes, and multiple inheritance.I have comments on each of these. Constructors should be allowed to have names other than that of the type to indicate their purpose, i.e., new, replicate, etc. Destructors have not been found to be necessary for most object oriented languages, other than C++, as most such languages include garbage collection. Think about not using C++ as a model and instead requiring garbage collection as a user option in Fortran 9x. Garbage collection should be easier to implement in Fortran than in C++. User defined polymorphism is discussed in my paper in too much detail to be examined here. Abstract types are necessary for any object oriented language. Stroustrup mentions the lack of well defined libraries in the earliest releases of C++ as his biggest mistake, learn from the mistakes of others. Multiple inheritance would be useful but not necessary. 043, OOP Capabilities, is similar to 033 and will not be discussed here. 049 Generalize Constructors into Generic Procedures: I am very enthusiastic about this proposal. I strongly recommend its adaption. 059, Pointers to Procedures, as I strongly believe that the proper treatment of object oriented capabilities requires treating procedures as comparable to data objects, I am enthusiastic about this idea as it removes one inconsistency from object oriented Fortran. However it requires more details than are given in this proposal. ISO/IEC JTC1/SC22/WG5 - N970 the requirements: 11, Aliasing Type Definitions, has some good ideas but is not general enough. I believe the problem they want to address requires a consistent definition of subtyping relations between all types and should not be allowed to be implemented arbitrarily. TO do this properly requires significant additions to the semantics of KIND values. My paper discusses this in great detail and will not be repeated here. 14, 14a, Parameterized Derived Types, are similar to Schonfelder's paper. I suspect he is the author of the British proposal. I am enthusiastic about this idea in general, but the limited proposals shown do not deal with the problems of parameterizing functions which use the types simultaneous with the types. My paper discusses this in great detail. 16, Allow Alocatable derived-type components, may be useful but should be done in a manner consistent with parameterized types. 18, Object Oriented Programming, is very similar to requirement 033 of X3J3/94-004r3s and will not be discussed in detail here. I want to make the following general points about the incorporation of object oriented capabilities in Fortran. 1. They are very desirable. They greatly increase the flexibility of the language with minimal impact on the performance and safety of the language, if implemented properly. The number of points where they are mentioned in the requirements suggests that a large variety of users agree with that assessment. 2. There are several capabilities commonly discussed in terms of object orientation: inheritance, templates (generic, parameterized types), exceptions, subclassing, subtyping, and polymorphism. Schonfelder's article only addresses generics. Unfortunately, the interrelation of those ideas means that a decision on one aspect will greatly affect the optimal decisions on the other aspects. As I have not seen detailed proposals on the other aspects, I cannot comment on them directly, but must instead point out some critical areas. 3. C++ is not the optimal model for such capabilities. In particular its templates are weak implementations of generic types, its class based model is not flexible, its polymorphism is ad hoc, and it lacks garbage collection. 4. Subtyping, and not subclassing, allows the greatest flexibility and potential for code reuse. The KIND value of Fortran 90 is the most obvious way of indicating subtyping, but its present usage as an explicit integer limits this role. The syntax and semantics of the KIND value should be considered carefully in developing object oriented capabilities for Fortran. In particular more intrinsic Fortran types should be considered. In addition, the use of KIND as a range of types and not as a single type should be considered. Subtyping on a record basis, as used in most object oriented languages, enhances a language's flexibility, but not as much as other forms of subtyping. In particular it would allow a more systematic exploitation of unsigned integers, infinite precision arithmetic, large integers, etc., which are of natural interest to the Fortran community. However, care needs to be taken with more flexible subtyping schemes to ensure type safety. 5. Even if subclassing and not subtyping is used, the KIND value is also a natural means of describing subclassing. 6. Schonfelder's article concentrates on parameterized user defined types, but does not address the need for simultaneous parameterization of the subprograms that use those types. 7. The template syntax of C++ and Ada for generics is awkward. A functional syntax, similar to Schonfelder's would be better. The example of the functors of ML seems particularly good. Care should be taken that the generics can be caused to be evaluated at compile time to maximize efficiency. However, they might have the option of evaluation at runtime to increase flexibility. I believe that the generics should be include shapes as well as KIND parameters and integers if they are to have acceptable flexibility. 8. A class based model, i.e., one that directly incorporates references to the object's proceeders in the object, particularly the use of the 'dot' notation, appears to be awkward for a language with the baggage of Fortran. It has the potential for a large increase in the syntax. It is possible to implement an efficient object orientated mode with a type based scheme, where the object contains an identifier of its type as an indirect means of specifying its procedures. Other schemes, e.g., cloning are also possible. 9. The proper handling of subtyping requires the subtyping of procedures, a necessary condition for subprogram pointers. The implementation of subprogram pointers should be considered simultaneous with the implementation of object orientation. 10. Think carefully about the implementation of dynamic polymorphism. It has great potential both for improved flexibility, and for decreased performance. I believe the flexibility is worth the potential cost, as I believe the cost can be adequately controlled by the user. However, many users of Fortran would disagree with me. Overall I hope I don't sound too critical. I am enthusastic about the proposal s as a whole, and, given the great improvements between FORTRAN 77 and Fortran 90, I have great confidence in the comittees's abilities. If there are any questions on the above, I am going to be on vacation in Southern Europe for the next three weeks. I will not be reachable by email. For most of the time from August 16 to Sept. 3, I will be with my inlaws in La Coruna Spain. From the US I might be reached at their number 011-34-81-213670. The digits 011-34 are US specific and will be different in other countries. Be aware that Spain leads odd hours and it is best to treat it as though it had England's not France's time zone. My wife and I will be the only English speakers in my inlaws' home and we will spend a lot of time on the streets. It may be easiest to reach me just before dinner, say 9-10:30 pm, Spanish time. After I return you can leave a message on my home phone (505) 662-3243 in the US. This is my first time using America Online. I suspect I will continue to use them for email, but my address might change after the free trial ends.