ISO/IEC JTC1/SC22/WG5 N1371 To: WG5 From: Data Subgroup Author: Lawrie Schonfelder Subject: Simplification of requirement Elaboration for increased functionality Date:21-JUN-1999 Original proposal WG5, during its consideration of the current requirements and work-plan for the production of Fortran2000, considered that a significant saving could be achieved by the following changes. The current description of function and language definition included in the draft document for data-object initialisation (constructors) should be removed. The current functionality and description for object finalisation (destruction) should be retained, perhaps with some modification and correction. To add at least some minimal compensatory functionality for the lost capability, the following relaxation should be made. Users should be permitted to override the intrinsic data-type structure constructor by the creation of procedures with a generic name that is the same as the type-name. The same rules should be applied, mutatis mutandis, as already exist for overriding intrinsic definitions for the semantics of intrinsic assignment and intrinsic functions by user written generic procedures. It is accepted that this loses some potentially useful functionality but it is believed that such a change would make a substantial reduction in J3s workload, while preserving much of the critical capability of the constructor/destructor requirement. Although this proposal will not in general allow the creation of user defined derived type objects with the PARAMETER attribute, nor will it make initialisation more generally supportable. It will, however, allow appropriately named user-defined type-conversion procedures to be used to create values of derived types. For example, given a type definition for variable precision arithmetic based on a type, TYPE NUMBER INTEGER::exp INTEGER,POINTER::sig(:) END TYPE NUMBER The user could define additional generic procedures called NUMBER. One specific version could take a single integer argument and another could take a character string argument; both designed to return a value of the NUMBER datatype. This will allow the following set of statements to be valid. type(NUMBER)::ten,c ten=NUMBER(10) c=NUMBER("2.99792458E+8") With a data type such as this the user has no simple way of using the intrinsic value constructors to create the structure values. Usable values can only be created by procedures written by the user to provide a more appropriate type conversion. In general, the logical name for such conversion procedures is the typename. In this example the name NUMBER is the appropriate. This minor change provides a valuable regularisation and aid to program readability and does not preclude the later addition of more extensive constructor functionality. Elaboration The very simple enhancement to the structure value constructor functionality proposed above does not allow initial values or constants of a derived type to be easily constructed. This functionality in Fortran depends of initial values being evaluated at compile time. Therefore, to permit user written procedures to be used to do this of necessity creates considerable linguistic and implementation complication. However, for most cases when using derived types it is not strictly initial (PARAMETER) values that are required but fixed values that are determined, like many specification expression values, when the object is declared and which cannot subsequently be changed. The comparison is with the size of an automatic object. In this case we want an "automatic" value for an otherwise fixed object. A simpler approach to this issue is, rather than try to create yet another subclass of procedures that obey complex sets of new rules, to introduce another declaration attribute spelled FIXED or CONSTANT. This attribute could indicate that the named entities being declared are also to be given a value in a manner syntactically similar to when PARAMETER is present, but now instead of the assignment expression being an initialisation expression it could be merely a restricted expression. For example, given the declarations above where ten and c are in fact variables but whose values we do not want to change. We could write type(NUMBER),FIXED :: ten=NUMBER(10),c=NUMBER("2.99792458E+8") The semantics for FIXED quantities would be that they could be evaluated only once for any instantiation. The expression used to evaluate them would be a restricted expression and could depend on primaries that were constant, or variables with defined values accessed via USE association or Host association, or were dummy arguments. If they involved the invocation of procedure it would have to be an intrinsic procedure or an accessible PURE or ELEMENTAL procedure. If a valid override for assignment were accessible this would be used rather than intrinsic assignment. To avoid having to reinitialise a module every time it became active we could insist on an additional restriction that for FIXED objects declared in a module, only constant restricted expressions are permitted. A FIXED object would be constrained to not being allowed to have its value redefined during the lifetime of the object. I am not in a position to suggest the detailed edits to implement this change but I believe they are relatively minor and constrained to chapters 5 and 6; with the possibility of an addition to 14 on scope, definition and undefinition. N.B. It is accepted that with this proposal the user could write an override procedure for any given typename that did not return a value of the named type. This would almost certainly be bad practice and could lead to the program being difficult to read. If such a procedure was used in a FIXED declaration context as above it would however fail since it would most likely produce an illegal type match detectable at compiletime.