ISO/IEC JTC1/SC22/WG5/N1251 Date: 23-jan-97 From: Manuela Zuern To: WG5 Subject: Recommendation for further work on data requirements References: WG5/N1189, WG5/N1215, x3j3/96-172 RECOMMENDATION FOR FURTHER WORK ON DATA REQUIREMENTS FOR FORTRAN 2000 This report gives recommendations to WG5 for further work on data abstraction and object oriented facilities, especially for the Las Vegas meeting of WG5 and X3J3 in Feb 97. Category-1 Items ================= The data subgroup should newly vote on following subjects * Operator Priorities (1.1.1; data-E1 ) As this is a new and very important item on the data list, this one should again be discussed to value its necessity within the group. * Expression Clarification - Object Oriented Programming (1.2.1; Repos. #18) I derive from the voting results and comments that not everybody realized the requirement #18 of the repository has nothing to do with suggestions for object oriented programming. The requirement is rather concerned with expression clarifications. It is also not yet clear to me if there have been made some expression clarifications in the Fortran 95 standard. And if yes, if they are sufficient. If this requirement is to be discussed in detail in Las Vegas, it should go to the MISC group because it has not much to do with data abstraction. * Remove INTENT(IN) requirement for OPERATOR, ASSIGNMENT (1.1.6; Repos. #56) As this item is quiet important for several applications it is recommended to discuss it shortly to value its necessity newly. It is recommended that all items with voting points 1.0 and higher which are not already worked on by x3j3 should be discussed in Las Vegas. Therefore the data subgroup should discuss the following subjects (with additional votes if necessary) Number Ref. Title 1.1.1 data-E1 Operator Priorities 1.1.2 #84 Overloading possibility for Pointer Assignment 1.1.3 #41 Renaming of in USE (1.1.6 #56 Remove INTENT(IN) requirement for OPERATOR, ASSIGNMENT ) 1.1.9 #11 Aliasing Type Definitions 1.1.12 data-E3 Develop a template/functor feature for the language 1.4.1 #75 Allow PUBLIC entities of PRIVATE type 1.4.3 data-E4 Separate specification of the access attributes of derived type components Most of the subjects concern a generalization and cleaning up of the interfaces and data abstraction area (1.1.x). The possibility of a general cleanup of this area should be considered. Discussions on special features should keep the others in mind. The same is valid for the Information Hiding features 1.4.x Category-3 Items ================ It is recommended that all items with voting points 1.0 and higher which are not already worked on by x3j3 should be discussed in Las Vegas. Therefore the data subgroup should discuss the following subjects (with additional votes if necessary) 3.1 #15 Remove name class irregularities 3.2 #57 Regularize KIND parametrization intrinsics 3.3 #58 Array Components of Array Structures 3.4 #72 Extend ALLOCATE to specify non-KIND type parameters Category-2 items ================ Constructor / Destructor ======================== As constructors and destructors have been valued to be important enough these features have to be discussed in Las Vegas (Vote-1). References for this subject are * N1187 * N1189 #87 and #89 Object Oriented Features ======================== It has to be put effort in implementing * single inheritance (Vote-3) and * some kind of dynamic binding (Vote-7) in the next revision of the Fortran Standard. Several parts which follow straight could be handled as suggested below: * As a basic work the paper x3j3/96-172 is recommended. * References for suggestions how single inheritance could be implemented: - Paper x3j3/96-172 - N1188 : Class inheritance and dynamic binding polymorphism * References for suggestions how dynamic binding could be implemented : - N1188 : Class inheritance and dynamic binding polymorphism * Generation of Objects: It is already worked on relations between data and procedures (methods) by x3j3 with implementing procedure pointers. Therefore there should not be put much (or any) time on discussing this subject. * Additional Visibility Attributes: Depending on how inheritance and class relation will be implemented it has to be looked on how additional visibility attributes at least for related classes could be implemented. (Vote-5, Vote-6) * Overridable Methods: Depending on how inheritance and class relation will be implemented it has to be looked on how overridable methods could be defined. A suggestion for this is already described in x3j3/96-172.(Vote-8) * Class Clause: Depending on how some things will be implemented it has to be discussed on wether and how a 'class' should be handled separately from a derived type (Vote-2). ==================================================================================== Changes in the subgroup report ============================== There is one point missing in the subgroup report N1238, which is now numbered as 3.5 Parameterized Derived Types (Repository #14) As there is already some work done on this subject, it will not be discussed in Las Vegas The new requirement specification data-E2 contains some errors. All 'apples' should be 'type_a_module', all 'bananas' should be 'type_b_module'. I appended the revision of data-E2 below : ============================================================================= Number: data-E2 Title: Allow a PUBLIC operator USEd in another module to be made PRIVATE for further use. Status: For consideration Basic Functionality: Having a module called type_a_module MODULE type_a_module ! ! Exports TYPE(type_a) and OPERATOR(==) for type_a ! PRIVATE TYPE, PUBLIC :: type_a INTEGER :: brand END TYPE type_a PUBLIC :: OPERATOR(==) INTERFACE OPERATOR(==) MODULE PROCEDURE eq_type_a END INTERFACE ! OPERATOR(==) CONTAINS LOGICAL FUNCTION eq_type_a ( a, b ) TYPE(type_a), INTENT(IN) :: a, b eq_type_a = a%brand == b%brand END FUNCTION eq_type_a END MODULE type_a_module and a second module which USEs 'type_a_module' MODULE type_b_module ! ! Exports TYPE(type_b) and OPERATOR(==) for type_b ! Also exports OPERATOR(==) for type_b, which may be not intentional ! USE type_a_module PRIVATE TYPE, PUBLIC :: type_b INTEGER :: brand END TYPE type_b PUBLIC :: OPERATOR(==) ! this always exports == for type_a INTERFACE OPERATOR(==) MODULE PROCEDURE eq_type_b END INTERFACE ! OPERATOR(==) CONTAINS LOGICAL FUNCTION eq_type_b ( a, b ) TYPE(type_b), INTENT(IN) :: a, b eq_type_b = a%brand == b%brand END FUNCTION eq_type_b ! ... some private module procedures needing 'type_a_module' and 'type_a' ... END MODULE type_b_module there is no possibility for TYPE_B *not* to export the '==' defined for TYPE_A if the '==' operator for TYPE_B has to be public. It is definitly no solution to move the USE statement for the TYPE_A module to the MODULE PROCEDUREs, because e.g. there could exist global module variables needing TYPE_A ... Allowing not to export any operator functionality for a public operator is very helpful in context with implementing different abstraction levels. =============================================================================