J3/03-165 To: J3 From: Malcolm Cohen Subject: Subclause 4.5.1 is unreadable Date: 18th March 2003 1. Introduction Subclause 4.5.1 "Derived type definition", up to the beginning of 4.5.1.1, consists of 4 pages of interspersed syntax rules, constraints, and text. It is an horrendous jumble and almost impossible to read. More structure could be given to this by dispersing the relevant syntax rules, constraints and text for the various sub-parts of a derived-type definition to the relevant sub-subclause (4.5.1.n). Furthermore, the ordering of the 4.5.1.n subclauses is apparently random, presumably to force people to read the entire chapter before even beginning to think they might have caught all the relevant material. For instance, "Default initialization" precedes both "Array components" and "Pointer components". But "Accessibility" follows "Final subroutines". 2. Discussion The structure is currently 4.5 Derived types 4.5.1 Derived-type definition 4.5.1.1 Derived-type parameters 4.5.1.2 Default initialization for components 4.5.1.3 Array components 4.5.1.4 Pointer components 4.5.1.5 Type-bound procedures 4.5.1.6 The passed-object dummy argument 4.5.1.7 Final subroutines 4.5.1.8 Accessibility 4.5.1.9 Sequence type 4.5.2 Determination of derived types 4.5.3 Extensible types 4.5.3.1 Inheritance 4.5.3.2 Type-bound procedure overriding 4.5.4 Component order 4.5.5 Type parameter order 4.5.6 Derived-type values 4.5.7 Derived-type specifier 4.5.8 Construction of derived-type values 4.5.9 Derived-type operations and assignment 4.5.10 The finalization process 4.5.10.1 When finalization occurs 4.5.10.2 Entities that are not finalized it ought to be something like 4.5 Derived types 4.5.1 Derived-type definition 4.5.1.1 Accessibility of the type 4.5.1.2 Sequence type 4.5.1.3 Determination of derived types 4.5.2 Derived-type parameters 4.5.2.1 Type parameter order 4.5.3 Components 4.5.3.1 Array components 4.5.3.2 Pointer components 4.5.3.3 The passed-object dummy argument 4.5.3.4 Default initialization for components 4.5.3.5 Component order 4.5.3.6 Component accessibility 4.5.4 Type-bound procedures 4.5.5 Final subroutines 4.5.5.1 The finalization process 4.5.5.2 When finalization occurs 4.5.5.3 Entities that are not finalized 4.5.6 Type extension 4.5.6.1 Inheritance 4.5.6.2 Type-bound procedure overriding 4.5.7, 4.5.8, 4.5.9 as above 3. Other quibbles with the current version: (i) the BNF term "" is inappropriate and ought to be just ""; it includes both data components and procedure pointer components. (ii) Constraint C418 combines two restrictions - one on the derived-type statement, the other on the SEQUENCE statement. Maybe it would be less confusing to have the SEQUENCE part of the restrictions on SEQUENCE instead of here? (iii) "Accessibility" should probably be split into type accessibility, component accessibility, and type-bound procedure accessibility. They really have nothing to do with one another. (iv) C442 should probably reference R439 not R438. At least, I cannot work out why it's meant to be applied to R439! (v) The SEQUENCE part of the does not really belong in the "component part" of the derived type - it makes the type itself be a "sequence type", it doesn't just affect the components. We can take the opportunity to call the PRIVATE spec the which is more explanatory. The should probably be too. (vi) The first sentence of note 4.41 should probably say that a structure "contains" a sequence of components, not that it "resolves into" such a sequence. With type-bound procedures a structure is, at least in theory, more sophisticated than a simple sequence of components. (vii) SERIOUS: [41:20-21] contradicts 4.5.1.8 on what the accessibility of a type-bound procedure is. What it really means (?) is that one accesses a type-bound procedure via an object of the type. Only (i), (iii),(v) and (vii) are reflected in the edits. Items (ii), (iv) and (vi) can be considered separately. A version of the results of this paper that does not include item (v) is also available. 4. Edits to 02-007r3 (1) Reorder subclause 4.5 as described above. (2) Rename to . (3) Replace the "type accessibility" definition (first 2 paragraphs of the old 4.5.1.8) with wording modelled on 5.1.2.1. (4) Split off the component accessibility and type-bound procedure accessibility definitions into their own places. (5) Rework PRIVATE/SEQUENCE bnf. (6) Insert cross-referencing mention of passed-object dummy arguments into 4.5.4. (7) Fix contradictory statement about type-bound procedure accessibility. The results of these edits are demonstrated in 03-166. [398:34] Fix cross-reference for accessibility of components and bindings (to 4.5.3.6 and 4.5.4 respectively). ===END===